Incorrect scope map fix

[DamianFekete]

Describe the bug
Scope mapping handling changed with #12112.

2915a70#diff-73bd44f873d78e3d71e6a0fa18644a304d562a4a9fd2e303e913f6ed20a0ad16R78-R83

• OidcAuthorizationCodeAuthenticationProvider.authenticate() calls OidcAuthorizationCodeAuthenticationProvider.getResponse())
• DefaultAuthorizationCodeTokenResponseClient.getTokenResponse does NOT add the scopes anymore. If no scopes are returned by default by the IdP, the scopes list is empty.
  • The comment If AccessTokenResponse.scope is empty, then we assume all requested scopes were granted. seems to say something completely different.
• Back in OidcAuthorizationCodeAuthenticationProvider.authenticate() the user info has to be loaded: this.userService.loadUser().
• OidcUserService.loadUser calls this.shouldRetrieveUserInfo(userRequest) which returns false now, because the scopes (userRequest.getAccessToken().getScopes()) is empty.
• Because of this the userInfo is not loaded (it is null) and can't be used for example in the userAuthoritiesMapper.

To Reproduce
Our scopes are configured like this:

spring.security.oauth2.client.registration.default.scope=openid,profile,entitlements

Use the userAuthoritiesMapper with a token-uri endpoint that doesn't return a list of scopes.

        http.oauth2Login()
                .userInfoEndpoint().userAuthoritiesMapper(this.userAuthoritiesMapper());

In the authorities mapper try to use the oidcUserAuthority.getUserInfo() (which is now null).

Expected behavior
oidcUserAuthority.getUserInfo() should not be null.

Sample
No sample yet.

Ping @sjohnr

[sjohnr]

Thanks @DamianFekete. Please see the blog post on cve-2022-31690 and related advisory for details about the fix and why it was applied.

The comment If AccessTokenResponse.scope is empty, then we assume all requested scopes were granted. seems to say something completely different.

See RFC 6749, Section 5.1 for details on why we assume that all scopes were granted. The unfortunate reality is that we cannot rely on that assumption in all cases, hence the fix.

I'll look into a fix for OidcUserService. In the meantime, you can apply the following workaround to consume the latest version of Spring Security:

@Configuration
@EnableWebSecurity
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            // ...
            .oauth2Login(Customizer.withDefaults());
        return http.build();
    }

    @Bean
    public OAuth2UserService<OidcUserRequest, OidcUser> oidcUserService() {
        OidcUserService oidcUserService = new OidcUserService();
        oidcUserService.setAccessibleScopes(Collections.emptySet());
        return oidcUserService;
    }

}

You can apply this workaround if it is acceptable to query the User Info endpoint on every login. If that's not acceptable in your case, let me know and I'll see about a different workaround.

[tobiaskrauss]

Thanks @sjohnr for your fast and helpful response. I was working with @DamianFekete on this issue. The workaround works fine for our application.
As we do not have too many users on this application, it should be fine for us that the user info endpoint is queried on every login.

[shresthaujjwal]

FYI, seeing same issue with 5.7.5 version too. Workaround works for me