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
