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 <oauth-boun...@ietf.org> on behalf of George Fletcher
<gffletch=40aol....@dmarc.ietf.org>
Date: Tuesday, March 24, 2020 at 11:48
To: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org>, Takahiko Kawasaki
<t...@authlete.com>
Cc: oauth <oauth@ietf.org>
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: george.fletc...@oath.com
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
