+1 to some standardization to the token
The URI would also allow for discovery and the ability for the provider
to define an endpoint in the XRD for the URI that allows "dumb mode"
token validation. This way, even if the resource owner doesn't know how
to "crack" the token locally, they could ask the provider to do it for them.
Thanks,
George
On 6/4/10 9:37 AM, Andrew Arnott wrote:
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
