Application with a user-defined OpaqueTokenIntrospector fails to start when spring.security.oauth2.resourceserver.opaquetoken.introspection-uri is set

When trying out Spring Boot 4.1.0-RC1 in a WebMVC based application (previously on Spring Boot 4.0), I noticed a bunch of new beans are now being created by the config classes imported by ReactiveOAuth2ResourceServerAutoConfiguration.

In Spring Boot 4.0, ReactiveOAuth2ResourceServerAutoConfiguration was annotated with @ConditionalOnWebApplication(type = Type.REACTIVE), but in 4.1.0-RC1 it is not. I understand this was done to enable Spring Security related concepts in non-webapps (#43978).

However, for WebMVC apps that don't need the reactive beans, it's resulting in creation of a bunch of additional unwanted beans.

I probably wouldn't have noticed, except that creation of one of those reactive beans is failing in our apps (caused by this assertion). In our apps, we've overridden the OpaqueTokenIntrospector bean, so that the corresponding assertion for WebMVC does not fail (our introspection endpoint does not use basic auth, so we have to configure the introspector slightly differently).

To work around this... we could define a ReactiveOpaqueTokenIntrospector bean to prevent the problematic bean from being created. However, this feels "wrong", because we don't need/want reactive introspection support at all in our WebMVC apps.

Alternatively, we could exclude ReactiveOAuth2ResourceServerAutoConfiguration. But that also feels wrong. IMHO the reactive resource server related beans should be opt-in in a WebMVC based app, not opt-out. In other words, @ConditionalOnClass({ Mono.class, BearerTokenAuthenticationToken.class }) does not feel like a "strong enough" condition to enable this autoconfiguration in WebMVC based apps. Mono being on the classpath doesn't necessarily mean the app needs reactive introspection support, since Mono could just be used internally by some other dependency, and not a key component of the app.

Start with ReactiveOAuth2ResourceServerAutoConfiguration and compare its conditions with OpaqueTokenIntrospectionConfiguration and ReactiveOpaqueTokenIntrospectionClientConfiguration, the files linked in the report. Reproduce a WebMVC application with the introspection URI and a user-defined OpaqueTokenIntrospector, then verify that unnecessary reactive resource-server beans no longer cause startup failure while reactive applications and non-web use cases remain supported.