I'm standing behind my 99.99% projection for the next 5 years. EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Thursday, June 16, 2011 9:04 PM To: OAuth WG Subject: Re: [OAUTH-WG] issuing multiple tokens > [Issuing multiple tokens] is not an important enough feature. Parsing an > array response when > 99.99% will be a single object array is annoying. I would agree... if I believed the 99.99%, but not if it will be 80% and falling in a year or two. A major benefit of OAuth2 is that resource servers only handle limited-lifetime, limited-capability access tokens so there is limited damage and easier recovery if one resource service is compromised. If the same access token works at all the resource servers that a client app uses, then an attacker that compromises one resource server can re-use the access tokens elsewhere. The bigger your portfolio of services, the worse the risk. > Also, what would you return in case of error? A single object? Yes. It is not that hard to test if JSON.parse(...) returns an array or a single object with an error field, or to notice the 4xx status code. > What is the client supposed to do if it gets an empty array? The delegation succeeded, but you don't need to use temporary credentials (perhaps client auth is sufficient, perhaps a [MAC] cookie was issued, perhaps the service is using URIs-as-capabilities...). Continue on to use the API. > Array with more than one token? If the client app hasn't bothered to write the extra code to handle multiple tokens then it just uses the first token. If separate tokens are now needed for servers that previously shared the same token, then the service has made a deliberate decision to increase security in a way that wasn't backwardly compatible. > *This* would be the hack... If this is something people want to deploy, > a full proposal end-to-end is required. And not now. I few proposals have been made in the past. Some try hard to leave the single token case alone, but always at a cost to complexity: eg the first token needs to be handled differently to the other tokens. Responding to William Mills' comments: >> Probably defining a token type of "multiple_tokens" would be my preference, >> and if you get that back then you have to parse an array of {type, token}*. >> What that array looks like could be JSON in the payload, or something else. >> That leaves the single token use case alone. This is a good example of how it is awkward to add multiple token support later. With this suggestion a service that starts issuing multiple tokens (eg for clients to access an enhanced version of an API) can't just add an extra token for the enhanced API that old clients will ignore. Instead, it has to change the top-level token_type, which will fail in all old clients. It also leaves other top-level mandatory fields such as access_token with confusing semantics. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
