Consider a lenient scope validation strategy in OAuth2ClientCredentialsAuthenticationProvider

[yonyes]

Expected Behavior

When a token request includes scopes that part of them aren't permitted, return the new token with only the permitted scopes

Current Behavior

When a token request includes scopes that part of them aren't permitted, it raises an internal exception, and the request answer is 400: { "error": "invalid_scope" }

Context

It's not a rare scenario that permissions of clients are changed and the clients themselves are not always updated immediately (or at all). It makes sense to generate the token with the scopes it allowed instead of failing the request.

The relevant code is in the OAuth2ClientCredentialsAuthenticationProvider.java

for (String requestedScope : clientCredentialsAuthentication.getScopes()) { if (!registeredClient.getScopes().contains(requestedScope)) { throw new OAuth2AuthenticationException(OAuth2ErrorCodes.INVALID_SCOPE); } }

[jgrandja]

@yonyes

Section 3.2.2.1 Access Token Scope states the following:

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.

Based on this, we'll consider a more lenient validation strategy.

[jgrandja]

We should consider adding OAuth2ClientCredentialsAuthenticationProvider.setAuthenticationValidator(Consumer<OAuth2ClientCredentialsAuthenticationContext> authenticationValidator), which would allow a consuming application to override the default scope validation.

The "authentication validator" feature exists in OAuth2AuthorizationCodeRequestAuthenticationProvider. See example.

[appchemist]

I want to take this issue, @jgrandja

I have a question.

When a token request includes scopes that part of them aren't permitted and a custom lenient scope validation is used, OAuth2AuthorizationCodeRequestAuthenticationProvider can generate token with scope containing unpermitted. So How about generating token with only permitted scopes & requested scopes by default?

[jgrandja]

Thanks for your interest @appchemist.

As soon as this issue is scheduled for a milestone, I'll reach out to you.

We'll be planning the features for the 1.1 release soon but I'm not sure yet if this will go into that release.

[adamleantech]

I'd like to upvote this request, we have a use case similar to this one with prefix scopes that we'd like to support and it would be relatively simple with a more lenient or configurable scope validation strategy. At the moment we're having to create quite an unpleasant workaround. I think a configurable strategy would be preferable

[jgrandja]

@adamleantech Please upvote the main issue comment.

[jgrandja]

This is now resolved via gh-1377.

The default scope validation can now be customized using OAuth2ClientCredentialsAuthenticationProvider.setAuthenticationValidator(Consumer<OAuth2ClientCredentialsAuthenticationContext> authenticationValidator).