Document the need to provide a SecurityWebFilterChain or WebSecurityConfigurerAdapter when using multiple OAuth 2 security components

[philsttr]

When I recently upgraded an application from spring boot 2.2.0.M6 to 2.2.0.RC1 that uses both OAuth2 Resource Server (opaque token support) and OAuth2 Client, I found that the OAuth2 Resource Server opaque token auto configuration is no longer applied. So this appears to be a change/regression from 2.2.0.M6 -> 2.2.0.RC1

In 2.2.0.M6, I see the following in the autoconfiguration report, indicating a successful configuration of the opaque token support:

   ReactiveOAuth2ResourceServerOpaqueTokenConfiguration.WebSecurityConfiguration matched:
      - @ConditionalOnBean (types: org.springframework.security.web.server.SecurityWebFilterChain; SearchStrategy: all) did not find any beans (OnBeanCondition)

   ReactiveOAuth2ResourceServerOpaqueTokenConfiguration.WebSecurityConfiguration#springSecurityFilterChain matched:
      - @ConditionalOnBean (types: org.springframework.security.oauth2.server.resource.introspection.ReactiveOpaqueTokenIntrospector; SearchStrategy: all) found bean 'opaqueTokenIntrospector' (OnBeanCondition)

In 2.2.0.RC1, I see the following in the autoconfiguration report:

   ReactiveOAuth2ResourceServerOpaqueTokenConfiguration.WebSecurityConfiguration:
      Did not match:
         - @ConditionalOnBean (types: org.springframework.security.web.server.SecurityWebFilterChain; SearchStrategy: all) found beans of type 'org.springframework.security.web.server.SecurityWebFilterChain' springSecurityFilterChain (OnBeanCondition)

It appears that when the OAuth2 Client AutoConfiguration executes, it defines a SecurityWebFilterChain, which prevents the ReactiveOAuth2ResourceServerOpaqueTokenConfiguration.WebSecurityConfiguration from applying.

If I remove the OAuth2 Client configuration properties, the Resource Server is configured properly.

Here is an example project with a unit test that shows the behavior. The test fails when using 2.2.0.RC1, but if you change the spring boot version to 2.2.0.M6, the test will pass.

[mbhave]

Thanks for the sample @philsttr. This is indeed caused due to the fact that ReactiveOAuth2ClientAutoConfiguration now explicitly defines a bean of type SecurityWebFilterChain causing ReactiveOAuth2ResourceServerOpaqueTokenConfiguration.WebSecurityConfiguration to back off. This change was introduced to fix #17949. This is an interesting use-case which I hadn't thought of when making that change. It's a bit tricky as we want to keep the @ConditionalOnMissingBean so that the auto-config can back off if there is a user-defined SecurityWebFilterChain. Let's see what we can do.

[philsttr]

Thanks for taking a look at this @mbhave !
Note that I originally noticed this when our @SpringBootTest integration tests that use an OAuth2 Client to communicate to the Resource Server under test started failing with authentication errors, since both the OAuth2 Client and Resource Server configuration end up in the same spring context. This seems like a fairly common scenario for integration testing resource servers.
After I noticed that test failure, I noticed the same symptom in a service that has both the OAuth2 Client and Resource Server configured in itself as well.

[wilkinsona]

As we add auto-configuration for more of Spring Security's features, I think we may have to accept that a certain amount of user configuration is required to use those pieces in combination. In this case, that would be a user-provided SecurityWebFilterChain that combines the two filter chains:

SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
	http.authorizeExchange((exchanges) -> exchanges.anyExchange().authenticated());
	http.oauth2ResourceServer(OAuth2ResourceServerSpec::opaqueToken);
	return http.build();
}

SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
	http.authorizeExchange().anyExchange().authenticated();
	http.oauth2Login();
	http.oauth2Client();
	return http.build();
}

The only alternative that I've been able to think of thus far is a contribution model for creating the SecurityWebFilterChain. I have some reservations about that as, given that there are multiple packages involved, it would have to be public API. It would feel like a return to the 1.x days where ordering of security components became both crucial and difficult to get right.

I'll keep giving this some thought, but I'm leaning towards documenting the need for a user-provided SecurityWebFilterChain when combining multiple pieces of security such as OAuth2 Client and Resource Server. That is a little cumbersome but it feels like the best option that I can think of given that current state of the art in Spring Security.

[wilkinsona]

We've decided that this is best addressed with documentation. The behaviour of the reactive auto-configuration is now aligned with the equivalent servlet auto-configuration where, for example, only one of OAuth2ResourceServerOpaqueTokenConfiguration.OAuth2WebSecurityConfigurerAdapter.opaqueTokenWebSecurityConfigurerAdapter() and OAuth2WebSecurityConfiguration.OAuth2WebSecurityConfigurerAdapter will be auto-configured.