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

[philsttr]

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.

[wilkinsona]

We made a step in your desired direction in #49807 but it sounds like we haven't gone quite far enough. I can't say more without knowing more about your app.

We find that the quickest way for us to understand the problem that you're facing is to look at a sample that reproduces it. This allows us to see exactly what code, dependencies, and configuration is involved. It also reduces the need for us to make educated guesses and the potential for us misunderstanding what you've described.

Please create a sample and share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

[philsttr]

Thanks for the quick look!

See unwantedreactorbeans.zip

The app will fail to start due to the failed assertion when creating a the ReactiveOpaqueTokenIntrospector bean.
However, the failed assertion is not the focus of this issue. The focus of this issue is that (I believe) the ReactiveOAuth2ResourceServerAutoConfiguration should not be triggered in this WebMVC app.

[philsttr]

Here's an idea I was contemplating.

Introduce two new properties:

• spring.security.oauth2.resourceserver.reactive.enabled - whether to enable the reactive resource server (ReactiveOAuth2ResourceServerAutoConfiguration). defaults to true in reactive webapps (WebFlux). false otherwise.
• spring.security.oauth2.resourceserver.synchronous.enabled - whether to enable the synchronous (non-reactive) resource server (OAuth2ResourceServerAutoConfiguration). defaults to true in servlet webapps (WebMVC). false otherwise.

The idea being...

• In WebFlux apps, ReactiveOAuth2ResourceServerAutoConfiguration will trigger by default, but OAuth2ResourceServerAutoConfiguration won't.
• In WebMVC apps, OAuth2ResourceServerAutoConfiguration will trigger by default, but ReactiveOAuth2ResourceServerAutoConfiguration won't.
• In non-webapps, neither will trigger by default.

This keeps the same behavior as Spring Boot 4.0 for any type of app, and still adds the capability to be able to enable the resource server in non webapps by setting the appropriate property to true.

[wilkinsona]

Thanks for the sample, @philsttr.

We generally try to avoid enabled properties unless absolutely necessary. In this case, it would be a shame for the auto-configuration to require non-web apps to opt in and I'd like to explore options for making things work automatically by improving the conditions.

The condition on the reactiveOpaqueTokenIntrospector bean is interesting. It will back off if there's no spring.security.oauth2.resourceserver.opaquetoken.introspection-uri property but, as you have observed, it fails if you have configured the introspection-uri but haven't configured client-id and client-secret.

One simple option that at least gets your sample to start would be to use conditions for all three properties and back off unless all three are set. While evaluating this option I've learned that Spring Security now supports the creation of an introspector without a client ID and secret due to changes made for null safety. I've reached out to the Security team to learn more about this change. If it's intentional and something that Boot should support, that will have a bearing on what we do here.

[philsttr]

I still maintain that there will rarely be a case where an app needs/wants both the synchronous and reactive resource server related beans, but that is exactly what happens currently if an app that configures resource server properties happens to have Mono on the classpath.

Here's another proposal.

Introduce spring.security.oauth2.resourceserver.implementation with two possible values:

• SYNCHRONOUS
• REACTIVE

In reactive webapps, it defaults to REACTIVE.
In any other app (servlet webapp or non-webapp), it defaults to SYNCHRONOUS.

In reactive webapps, setting it to SYNCHRONOUS would be an error.
In servlet webapps, setting it to REACTIVE would be an error.
In non-webapps, any value works.

For reactive webapps, you get the beans from ReactiveOAuth2ResourceServerAutoConfiguration by default.
For other apps (servlet webapp or non-webapp), you get the beans from OAuth2ResourceServerAutoConfiguration by default.
For non-webapps that are primarily reactive, a user could set it to REACTIVE to get the reactive beans instead of the synchronous beans.

And if you really want to support both the reactive and synchronous beans from both autoconfig classes in the same app, you could add a third option that could be set by a user (and used in any type of app) if needed:

• BOTH

I think the use case for having both sets of beans would be extremely rare, so BOTH might not be worth supporting unless there is demand for it (perhaps wait to introduce it until SB 4.2 if needed)

Naming could probably be improved, but this should explain the idea

I think this approach provides intelligent defaults and follows the principal of least surprise for each type of application (especially for users upgrading)

[philsttr]

One more proposal. This one does not involve a new property.

• ReactiveOAuth2ResourceServerAutoConfiguration is conditional on:
  • Mono exists && (reactive-webapp || non-webapp)
  • expressed more simply as Mono exists && !servlet-webapp
• OAuth2ResourceServerAutoConfiguration is conditional on:
  • (servlet-webapp || non-webapp)
  • expressed more simply as !reactive-webapp

Results in the following behavior:

• For reactive webapps, you only get the beans from ReactiveOAuth2ResourceServerAutoConfiguration (similar to SB 4.0)
• For servlet webapps, you only get the beans from OAuth2ResourceServerAutoConfiguration (similar to SB 4.0)
• For non-webapps without Mono on the classpath, you only get the beans from OAuth2ResourceServerAutoConfiguration
• For non-webapps with Mono on the classpath, you get both beans from OAuth2ResourceServerAutoConfiguration and ReactiveOAuth2ResourceServerAutoConfiguration. And you can disable whichever you don't need by excluding the unneeded autoconfiguration class

This one is simpler in that it doesn't have a new property, and it maintains the same behavior as SB 4.0 for both servlet and reactive webapps. It's also nice for non-webapps that don't have Mono on the classpath. The only annoying case is for non-webapps with Mono on the classpath, because those apps would get both sets of beans by default, where I expect apps would only need one or the other, not both.