I get the desire to have multiple tokens, but the real cost is the explosion in complexity for every party in the system. This is especially true if you allow the client to specify a more fine-grained and structured resource target than a scope string, but even with a scope it’s really common to have a set of different resource servers that respond to the same scope. The biggest burden is on the client which now has to map different access tokens from the same request to different resource targets, some of which it might be discovering at runtime. And then you have to figure out what to do at the AS if the user only approves one resource, or even worse, one scope that covers multiple resources. You need to have very clear logic of how you separate these into different access tokens, and how you signal that to the client. And then there’s the question of refreshing things once tokens expire (because of course they could have different lifetimes) — in OAuth that implies multiple refresh tokens, in XYZ that implies multiple transaction handles. I’m not sure this complexity in the general case is worth it to solve this specific issue, which seems like a bit of an edge condition to me. I really don’t think we should make simple clients pay this complexity cost if they don’t have to.
XYZ does make asking for several different access tokens in multiple requests potentially easier through use of the “user_handle” construct (imported from the PCT concept in UMA2). This lets you say that you as the client are saying it’s the same user and the same client for a different resource set, and that might be enough for the AS to just let you have a token with the first call to it and not have to get the user involved again. But this doesn’t really help if you need to ask the user consent a bunch of times, which seems to be what people are really after solving when they talk about getting multiple access tokens. The problem isn’t asking the AS, the problem is asking the user, and we’d really like to bother them once and only once. So maybe the question isn’t so much about multiple access tokens, but actually about multiple simultaneous transactions in a single request. Because if you’re doing that, you have a kind of natural separation between the requests (each would get its own transaction keys and tokens), but you could combine the interaction portion when it’s needed and only bother the user once for multiple things. — Justin On Jul 23, 2019, at 6:10 AM, Neil Madden <neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>> wrote: If we follow the principle of least authority then a token should be scoped as narrowly as possible to a particular resource server/resource/time period/transaction. The security topics BCP has already gone quite far down this path in its recommendations: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.3 . Least privilege naturally leads to clients needing more tokens, so we should make obtaining (and using) multiple tokens as frictionless as possible. For an example of this, see the work done by my colleagues to simplify juggling multiple access tokens for different resource servers - https://www.npmjs.com/package/appauthhelper . The library allows the developer to specify which scopes are used for which RS: resourceServers: { "https://login.example.com/oauth2/userinfo": "profile", "https://rs.example.com/": "rs_custom_scope" }, The library then takes care of making multiple requests to get appropriately-scoped access tokens and then attaching them to appropriate requests. But the more resource servers you need to access, the more tokens you need and the more requests you have to make. There is therefore currently a "tax" on least privilege use of access tokens as it is all on the client to juggle these requests, giving an incentive for clients to instead request Big Tokens that grant lots of authority in a single request/response. -- Neil On 22 Jul 2019, at 22:46, Dick Hardt <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> wrote: Hi Neil I see that you are looking at how to modify Justin's proposal, and I'm looking at what are the requirements. Ignoring the specifics, is there a reason why multiple tokens need to be returned in the same request? On Mon, Jul 22, 2019 at 9:41 AM Neil Madden <neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>> wrote: On 21 Jul 2019, at 22:22, Dick Hardt <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> wrote: Hi Neil, I agree that an access token that is usable across resources is problematic. How are you thinking multiple access tokens would be returned? Well there are lots of possible ways, e.g.: { "tokens": [ { "resource": "https://res1";, "access_token": "..." }, { "resource": "res2", ...}, ... ] } I'm not particularly wedded to any format. Why do you think the request needs to return multiple tokens rather than making a separate request for each token? That would seem to simplify the request and response as context would only need to provided for the one access token. Note that in Aaron's proposal we have a "user" section on (presumably) every access token response, which indicates a userinfo endpoint that itself needs an access token. So either the same access token is used to access that userinfo endpoint (which means that the RS can also access the userinfo endpoint), or else we already need to return a second access token in the same request, e.g.: { "access_token": { "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type": "bearer" }, "user": { "id": "5035678642", "userinfo": "https://authorization-server.com/user/5035678642";, "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk" } } _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
