Running into issues with upgrading 3.1.6 project to 3.2.0, using webflux + oauth2-resource-server:

Caused by: java.lang.IllegalArgumentException: authenticationManager cannot be null
    at org.springframework.util.Assert.notNull(Assert.java:172)
    at org.springframework.security.web.server.authentication.AuthenticationWebFilter.<init>(AuthenticationWebFilter.java:94)
...

Looks very similar to https://github.com/spring-projects/spring-boot/issues/37504

To reproduce: * webflux + oauth-resource-server starters - Initializr link * run contextLoads() test

Looks like in 3.2 the ReactiveUserDetailsServiceAutoConfiguration backs off because of the @ConditionalOnMissingClass ReactiveOpaqueTokenIntrospector that oauth-resource-server brings along. In my @SpringBootTests I don't have any resource server configured, I'm expecting it to fall back to the default WebFluxSecurityConfiguration, as it did in 3.1.6

Looking at this, there would be another problem when you have oauth2-login on the classpath, which brings along ClientRepository ?

Comment From: wilkinsona

Thanks for the report. It looks like the resource server-related auto-configurations are enabling web security in situations where they won't actually provide everything that's needed for that to succeed. We need to adjust the conditions on their WebSecurityConfiguration classes.

Comment From: tgeens

@wilkinsona I'm very surprised with this change, Spring Boot 3.2.1-SNAPSHOT suddenly backs off applying any security ?

Even if oauth2-resource server is not "properly configured", I still expect everything to fall back to the ReactiveUserDetailsServiceAutoConfiguration ?

Given the following test:

@Test
void testUnauthorized(ApplicationContext context) {
    var client = WebTestClient.bindToApplicationContext(context).build();
    client.get().uri("/").exchange().expectStatus().isUnauthorized();
}
  • Spring Boot 3.1.6: OK - HTTP 401
  • Spring Boot 3.2.0: FAIL - context fails to load
  • Spring Boot 3.2.1-SNAPSHOT: FAIL - HTTP 404

Comment From: wilkinsona

That's not this change, it's https://github.com/spring-projects/spring-boot/issues/35338 that is causing that to happen. It failed with 3.2.0 as it wasn't backing off correctly and things were being left in a partial, broken state.

If resource server is on the classpath but you're not actually using it in certain situations then, as described in the release notes, you should define your own user details service in those situations.

Comment From: tgeens

Thanks for the quick reply.

I realize #35338 is the original cause, but I'm not sure I understand. Should I open a new issue or do you consider this expected behaviour ?

Comment From: wilkinsona

It's the expected behavior in order to avoid the unwanted warning described in #35338 that's triggered when the in-memory user details service is configured.

Comment From: wilkinsona

As described in #38753, we need to find a better way to fix this.