Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary, to write that agreement as a separate spec (perhaps an extension).
In particular, I wouldn't like your proposal because of the use of equals and ampersand, both of which would need to be URL encoded so developers couldn't copy/paste the token as easily. For Facebook, it's important that the access tokens are as short as possible; other sites may have different requirements. On Jun 4, 2010, at 6: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 <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
