Re: [OAUTH-WG] Transaction Authorization

[Neil Madden <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
> 
>> On 21 Jul 2019, at 22:22, Dick Hardt <[e-mail]> 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"
>       }
>     }