+1, but why only partially?
I would like to add another use case for a standardized token format.
Suppose a software vendor wants to built and sell a standard software
component (service), e.g. an address book service, which is secured
using OAuth2. Having a standardized token format would make the
integration of that "standard software" within customer deployments
easier. Indeed, the customers authorization server must "speak" that
token format.
SAML would be a natural candidate from my point of view, a more compact
variant (based on JSON?) would be fine.
I think, a standard token format should be covered in a separate
specification.
regards,
Torsten.
Am 04.06.2010 15:37, schrieb Andrew Arnott:
Having just implemented OAuth 2.0 web server flow, it was great to be
able to issue an "opaque" access token to the client. This access
token is in an encrypted format that only the resource server
understands. I feel pretty good about this approach as it lends to
high security and tokens that only the client needs to store (or not
at all).
But I'm wondering about the resource server that trusts multiple auth
servers, which each have their own access token format. Without even
a standardized way for an access token to express what format it is
in, a resource server may have to just try decoding the token each
known way until one "works".
Proposal: perhaps the access token can be /mostly/ opaque, but not
quite. For instance:
The access token is in the format: /format=URI&opaquevalue/
Where URI is an arbitrary URI assigned by the auth server to assist
the resource server in interpreting the /opaquevalue/ part of the token.
Feedback?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
