OAuth has been successful because of its simple architecture and because it is based on actual deployment experience. Offering multi-token responses would be premature standardization. I am not convinced that adding it later would entail any real technical difficulty.
EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Friday, June 17, 2011 12:41 AM > To: Eran Hammer-Lahav > Cc: Manger, James H; OAuth WG > Subject: Re: [OAUTH-WG] issuing multiple tokens > > this is kind of a self-fulfilling prophecy. If we do not encourage > implementors > to use service-specific tokens by supporting it in OAuth most people will not > consider it. > > As James pointed out, there are good reasons to use service-specific tokens > in multi-service environments. That's why Deutsche Telekom employs a strict > security policy to use different tokens for different services. And as a > multi- > service provider an increasing percentage of our apps need to access > multiple services. That's why we have implemented support for issuing > multiple tokens in a single authorization flow. We will have this feature in > production before IETF-81. > > regards, > Torsten. > > Zitat von Eran Hammer-Lahav <e...@hueniverse.com>: > > > 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
