Avoid error in OAuth2ClientPropertiesMapper when CommonOAuth2Provider is not available

[nstdio]

This commit prevents NoClassDefFoundError when CommonOAuth2Provider is not present on classpath. This module does not declare explicit dependency on spring-security-config but was using CommonOAuth2Provider without guard statement.

[nstdio]

Original issue was mistakenly reported in spring-projects/spring-security#18036. I'll be happy to reference it in commit message once it is transferred.

[danish-ali]

Nice guard to avoid NoClassDefFoundError when Spring Security isn’t present. Two thoughts:

getCommonProvider’s signature references CommonOAuth2Provider; some JVMs may resolve signature types at link/verify time. To stay load-safe, consider moving the reference into a nested helper used only when present, or use a reflective path (returning Object/Enum<?>).

The static presence check is fine, but a lazy/memoized check inside getCommonProvider is often safer in multi-classloader/AOT contexts.
Could we also add an ApplicationContextRunner test with a FilteredClassLoader("org.springframework.security.config.oauth2.client.CommonOAuth2Provider") to verify the mapper loads and returns null instead of throwing?

[wilkinsona]

Thanks for the proposal but this won't fix the problem as the class still references CommonOAuth2Provider in its signature. We also don't intend for Boot's OAuth2 client support to be used without the spring-security-config module. This is shown in the starter where spring-security-config is an API dependency.

It sounds like you're not using the auto-configuration. If you were yet it was not backing off correctly in the absence of spring-security-config then that would be something that we'd want to fix. Please open a Spring Boot issue (issues cannot be transferred from Security to Boot) if you'd like us to investigate. However, please note that directly using classes from Spring Boot's auto-configuration (such as OAuth2ClientPropertiesMapper) without having your own classpath checks in place isn't supported and there are many cases where it will not work.

[wilkinsona]

The static presence check is fine, but a lazy/memoized check inside getCommonProvider is often safer in multi-classloader/AOT contexts.

@danish-ali thanks for trying to help, but please leave this sort of subjective and stylistic feedback to the core team as it may result in wasting a contributor's time if we do not agree.

[nstdio]

@wilkinsona Yeah that makes sense to me. Thanks for clarification.