Customize when UserInfo is called

[youlabi]

Describe the bug
org.springframework.security.oauth2.client.oidc.userinfo.OidcReactiveOAuth2UserService#getUserInfo calls OidcUserRequestUtils::shouldRetrieveUserInfo that uses the scopes in the OAuth2AccessToken to determine whether it should fetch user infos or not.

In the non-reactive OidcUserService shouldRetrieveUserInfo was extended to return true if either, the access token has no scopes or the accessibleScopes is empty:
fde26e0

This fix was not applied to the reactive version

To Reproduce
Set up OIDC server to return an Opaque Token, which automatically has no scopes.

Expected behavior
Userinfo endpoint is called

Sample

No sample present

Reports that include a sample will take priority over reports that do not.
At times, we may require a sample, so it is good to try and include a sample up front.

[youlabi]

See related issues:

• Incorrect scope map fix #12144
• Incorrect scope map fix #12205

[sjohnr]

Thanks for the report, @youlabi! I think the OidcReactiveOAuth2UserService needs to be aligned with OidcUserService by applying both this fix and the addition of accessibleScopes.

Would you be interested in submitting a PR?

[youlabi]

I can not promise anything :). Can you please forward me to some resources and things I need to know, on how to submit a PR ?

Regarding the actual change. This seems to me like it is exactly the same logic duplicated in two places. Should this be kept this way? This seems highly inefficient, and the next fix will again have to be transferred and likely be forgotten.

Another question I am unsure about: why does the reactive stack make use of a static class? Is this just legacy ?

[sjohnr]

Hi @youlabi, thanks for the reply.

Another question I am unsure about: why does the reactive stack make use of a static class? Is this just legacy ?

Sadly, I don't know the answer to that question. It's just however the developer chose to do it.

Regarding the actual change. This seems to me like it is exactly the same logic duplicated in two places. Should this be kept this way? This seems highly inefficient, and the next fix will again have to be transferred and likely be forgotten.

It is OK to duplicate logic when needed. It is not a goal of Spring Security to eliminate all such duplication as this would be an untenable goal. However, I see your point that duplication can cause issues like this. In this case, it looks like the static class can be used to reduce duplication, so if you wish, you can refactor the code so both OidcReactiveOAuth2UserService and OidcUserService use the same static class and same logic. This refactoring is possible because the static class is package-private.

I can not promise anything :). Can you please forward me to some resources and things I need to know, on how to submit a PR ?

Thank you so much! That's completely okay, I'm here to help. Take a look at the contributing document which will walk you through most of what you need to know.

I will mention that because you have correctly categorized this issue as a bug, it would be nice to base the change on the 5.7.x branch, but this is not required. If it's easier for you to use main, I can rebase the change for you. We also use a forward-port process to propagate changes from 5.7.x to main. This is again something you don't need to worry about, I can handle it for you!

Any other questions, please let me know.

[sjohnr]

Oh, I just remembered one more thing. If/when we make a fix on the 5.7.x branch, we probably will not want to add the setter for accessibleScopes because it would be a new API, and bug fixes should not introduce new APIs. So when performing the change, make sure not to add a setter for it. We can add the setter in the 6.2 release since the change will not be a breaking one.

Looking over the code in OidcUserRequestUtils, I'm also noticing that the logic does not line up with what's in OidcUserService. That makes this change a little trickier. Feel free to continue discussing if you want to talk through the changes.

[youlabi]

Thanks for all the input.

I noticed that shouldRetrieveUserInfo is alwyas private and or final, or to put it differently, it is behaviour that can not be overwritten by the user. So I can not extend OidcUserService and adapt the behaviour.

Is this because, this is standardized OIDC / OAuth2.0 behaviour? This might explain why it is private / static code that can not be changed.

What do you think about this implementation:

• Use OidcUserRequestUtils for both OidcUserService and OidcReactiveOAuth2UserService
• Both OidcUserService and OidcReactiveOAuth2UserService have a property Optional<Set> accessibleScopes that is empty by default
• They both have a setter setAccessibleScopes(Set accessibleScopes)
• Depending on whether accessibleScopes is empty or set, either call OidcUserRequestUtils.shouldRetrieveUserInfo(OidcUserRequest userRequest) or OidcUserRequestUtils.shouldRetrieveUserInfo(OidcUserRequest userRequest, Set accessibleScopes)
• OidcUserRequestUtils stores the default accessibleAcopes and uses them if none are provided (i.e. when calling the first method)

[youlabi]

@sjohnr , I have a question regardingyour fix fde26e0 for #12144

If https://www.rfc-editor.org/rfc/rfc6749#section-5.1 says, that "returning no scopes means all requested scopes were granted", shouldn't the AccessToken actually be populated with all of those granted scopes earlier, if the scopes in the response was not set. It seems to me, that the fix is in fact incorrect, and more of a workaround because the way I understand it, we should have probably filled the at some place earlier.

What if the server returns an access token with an empty scope list. Then assuming that all scopes were granted is not right.

[youlabi]

Unless of course an empty scope list is not permitted, in which case the workaround is fine, however, it still seems like a workaround instead of a fix :)