> [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
