Extension point to limit the scopes granted to a token

[metacubed]

When a token is generated for either client- or user-based grants, it would be useful to provide a generic mechanism to reduce⁺⁺ the scopes which are present in the granted JWT.

The list of granted scopes starts with those available to the client. This list can be reduced by many different kinds of constraints. These are just a few examples (not an exhaustive list):

• The resource-owner consenting to only a subset of scopes
• The scope claim in the token request (Scopes for Claims and The claims Request Parameter #212)
• Custom policies defined in a larger authorization-server product (Add a basic authorization server policy for scope validation #187)

I would propose injecting a chain of TokenScopeCustomizer implementations, which take in the initial token request and the initial granted list of scopes, and returning a subset of those scopes at the end of the chain.

⁺⁺ I think it is reasonable to only reduce the available scopes, not add to them. However, it might turn out that there are use cases for both.

[metacubed]

Does this seem reasonable, @jgrandja? I can give this a try if it fits the overall design.

[jgrandja]

Thanks for the details @metacubed.

I agree that we do need the capability to restrict/reduce/add scopes and/or claims during the authorization process. I have captured this in #139 at a very high level:

Provide plugin mechanism for Policy Enforcement

Instead of a TokenScopeCustomizer, I would prefer to design a high-level abstraction around Policy Enforcement so it can fulfill many uses cases.

Would you mind logging the details in this ticket over to #139 and close this one? I'd like to have all the information captured there.

Before we start work on a Policy Enforcement abstraction, some R&D work needs to be performed on existing providers to understand how they have implemented. Would you be interested in doing some R&D so we can learn more on what design would work best?

[metacubed]

Reworded and moved over to the umbrella ticket here.

Re. a single interface for all token customization, not sure if that will help or harm usability. I can see it becoming quite intimidating 😄.

And yes, let me know how I can help with the Policy Enforcement investigation, @jgrandja.

[jgrandja]

Thanks @metacubed.

I just realized that the recently added OAuth2TokenCustomizer could very well realize your use case.

A @Bean of type OAuth2TokenCustomizer<JwtEncodingContext> will allow you to customize the scope claim in the Jwt.

Follow the conversation in this thread to see examples on how to customize a Jwt.

Please let me know if this works for your use case.