> At some level that's true and I'll admit that I characterized it as a
> gateway approach - it's a natural step when you sell a gateway style
> product:) But the authorization server doesn't necessary have to be
> a distinct entity, it could be an additional endpoint at the service.
It could, but that just adds a whole new protocol exchange without obviating
the need for SAML support in the service.
> At another level it's nothing more than exchanging SAML for some
> session token. But it's happening within the framework of a standard
> which is good for interoperability.
I suppose so, but cookies predate OAuth, and are simpler, and a session
based on TLS is much stronger than either of them.
> The token is both issued and consumed by the same party (in the most
> common use case anyway) and it is opaque to the client so it can
> contain whatever that entity deems necessary in whatever format makes
> the most sense for it.
I don't think the token is consumed by the issuer when you split off the
token issuer. That demands a standard format, and now we're deep into the
idiotic arguments about XML vs JSON, and I'm not going there.
-- Scott
