Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher <[e-mail]>]

I think one of the problems we have in being super specific about how 
the JWT access token is constructed is that is means it's not possible 
for many organizations to follow. How scopes are implemented is very 
varied across deployments which means that some may conform to the 
perspective of the spec and many may not.

Personally, I'm not a big fan of trying to use scopes for fine-grain 
authorization. I don't think that is what they were intended for when 
originally designed. (This can be seen by the RAR spec introducing a 
completely different way of specifying fine-grain authorization 
context.) Even in multi-tenant systems, I don't see issues with using 
sub-resource scopes as each tenant should define the scopes that make 
sense for that tenant. I don't think the AS needs to understand the 
scopes, just provide a mechanism to issue the correct scope under user 
consent to the client and let the RS apply the authorization policy when 
it gets the scopes out of the token.

I'll wait for your response to my other feedback :)

On 3/24/20 3:07 PM, Vittorio Bertocci wrote:
> You are too fast 😊 I am still replying to your other comments! 😃
> Yes, it is possible for resource servers to define sub-resource specific scopes, but it cannot be mandated- and it can be extremely problematic when your AS is multitenant. The resource identifier in those scenarios can be a LONG URI, and forcing people to do scope stuffing (eg : csutomresource:// 1f150b81-c98e-45ec-8252-ab47ef0645ff/read) is hard from the management, provisioning and even bandwidth use standpoints. I have experienced this firsthand when Azure AD moved from v1 style resource identification (where resource was a mandatory request param) to v2, where the resource was inferred from the scopes via scopes stuffing.
>
> From: OAuth <[e-mail]> on behalf of George Fletcher <gffletch=[e-mail]>
> Date: Tuesday, March 24, 2020 at 11:48
> To: Vittorio Bertocci <Vittorio=[e-mail]>, Takahiko Kawasaki <[e-mail]>
> Cc: oauth <[e-mail]>
> Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
>
> Focusing just on this comment...
>
> This assumes the system uses a specific implementation of scopes values (e.g. 'read', 'write', 'delete'). It is very possible that in the context of a calendar services and an inbox service... the system defines scopes like 'cal-r', 'cal-w', 'mail-r', mail-w' in which there is no ambiguity.
> On 3/24/20 2:14 PM, Vittorio Bertocci wrote:
>
>    I don't think the rule referring to the "scope" parameter is worth being
>
> defined. That "aud" is missing but "scope" is available is enough for
>
> resource servers. In other words, if "aud" is determined based on the
>
> "scope", why do we have to set "aud" redundantly?
>
> Scope is actually not sufficient for many resource servers. Whenever an RS
>
> is facading a collection of existing finer grained resources, scopes
>
> representing permissions might be ambiguous - if my API facades both
>
> calendar and inbox, what does the "read" scope refer to? Having an audience
>
> resolves that ambiguity.
>
>

-- 
Identity Standards Architect
Verizon Media                     Work: [e-mail]
Mobile: [phone]           Twitter: http://twitter.com/gffletch
Office: [phone]           Photos: http://georgefletcher.photography