Ultimately it is the Resource Authorization Server that will decide what scope to issue for the access token. It may have its own policies around scopes based on user/client/IdP and can make the final decision.
If the ID-JAG contains a scope claim, it's because the IdP allows the admins to configure what scopes a client is allowed to request for a resource. It is expected that the Resource AS should respect the request if appropriate. In other words, the Resource AS should not blindly trust the scope values in the ID-JAG. To make this more concrete, let's use an example of a chat app as the Resource. The chat app might have its own policy that any client can get read/write access to the channels a user is already in, but Cross App Access clients using an ID-JAG do not get access to join new channels. The API could use a scope value of "channels:join" and only allow clients that have gone through an interactive user consent flow to request that scope. If an ID-JAG contains the "channels:join" scope, the chat app's AS would not include that scope in the access token issued. This is analogous to the text in Section 3.3 of RFC6749 treating the "scope" parameters as a request from the client that may or may not be granted. "The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions." Aaron On Thu, Dec 4, 2025 at 11:25 PM Judith Kahrer <judith.kahrer= [email protected]> wrote: > Dear OAuth WG, > > while reading through the 01 draft of the Identity Assertion JWT > Authorization Grant ( > https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/01/) > and implementing it, we came across some open questions regarding the scope > of the access token for the Resource that we didn't find any answer in the > draft or related specs. > > TLDR; The main question that we have is, does the Resource Authorization > Server issue in the access token whatever (scope) is in the ID-JAG? > Below follows a longer elaboration of my thoughts about how to process the > ID-JAG regarding scopes. > > The ID-JAG is a grant. A grant is always tied to a scope (implicitly or > explicitly). Shouldn't the scope claim in the ID-JAG be required then? In > that way it becomes clear for the Resource Authorization Server what the > subject consented to (grants access to). According to RFC 7521, section > 4.1, (https://datatracker.ietf.org/doc/html/rfc7521#section-4.1), "the > authorization server MUST limit the scope of the issued access token to be > equal to or less than the scope originally granted to the authorized > accessor." If the scope is missing in the grant, the Resource Authorization > Server has to make assumptions about the default scope. > Since the IdP Authorization Server and the Resource Authorization Server > are two different entities in two different trust domains, their policies > may differ. There is a risk that the default scope at the IdP Authorization > Server is not the same as the default scopes at the Resource Authorization > Server, which basically results in the subject consenting to one thing but > the client getting authorized for something different. Therefore, I think, > the scope claim in the ID-JAG should be REQUIRED. The scope of the access > token is the intersection of the scope in the ID-JAG and the requested > scope in the token request. At the end it is at the discretion of the > Resource Authorization Server what scope to include in the access token as > long as it doesn't violate the grant. At least, this is how I think grants > should work. > > In my opinion, section 4.4.1 should point to RFC 7521 for validating the > scope claim. The reference to RFC 6749, section 3.3 is not appropriate for > validating the scope claim because it is solely about the scope request > parameter and does not even mention its relation to the authorization > grant. The Resource Authorization Server must not treat the scope claim > like the scope request parameter. While it's ok to ignore a request > parameter, ignoring a grant and the scope of the grant defeats its purpose. > Don't you agree? > > I get the feeling that there is quite some duplication of policies in the > IdP Authorization Server and Resource Authorization Server with regard to > scopes. One needs scopes for the grant, the other for issuing access > tokens. Who is responsible for defining the scopes and deciding what ends > up in the access token? In my opinion, it should be the Resource > Authorization Server because it has the authority to grant access to > resources. If that's not the case and the Resource Authorization Server > issues whatever is in the grant, then it's simply an (access) token issuer > for the IdP Authorization Server. What's the purpose of an authorization > server if it doesn't own any policy? Can you elaborate more on the use > cases? > > I went down a rabbit hole the more I thought about scopes and I have some > more questions. I may eventually start a new mail thread for those to keep > this conversation focused on how the Resource Authorization Server should > handle the scopes of the ID-JAG. > > Best regards, > Judith Kahrer > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
