ReactiveOAuth2ResourceServerWebSecurityAutoConfiguration annotated with wrong condition

[michael-wirth]

The reactiveJwtSecurityFilterChain bean is initialised even if a custom SecurityWebFilterChain bean is registered.
The problem is that the ReactiveOAuth2ResourceServerWebSecurityAutoConfiguration configuration is annotated with ConditionalOnDefaultWebSecurity.

The ConditionalOnDefaultWebSecurity only handles the SERVLET application, but fails for REACTIVE.
The condition checks if a bean of type SecurityFilterChain is missing, but for the reactive stack, it must check for SecurityWebFilterChain

See
https://github.com/spring-projects/spring-boot/blame/699d9c34c3e2ead02b704dc7c1c1d1747684b99b/module/spring-boot-security-oauth2-resource-server/src/main/java/org/springframework/boot/security/oauth2/server/resource/autoconfigure/web/reactive/ReactiveOAuth2ResourceServerWebSecurityAutoConfiguration.java#L54

I assume a new ConditionalOnDefaultReactiveWebSecurity condition is required, or the existing ConditionalOnDefaultWebSecurity should cover both cases.

[seonwooj0810]

I was able to confirm this on current main. ReactiveOAuth2ResourceServerWebSecurityAutoConfiguration is annotated @ConditionalOnDefaultWebSecurity, and that meta-annotation's DefaultWebSecurityCondition (in the ...web.servlet package) is built entirely around the servlet stack:

• @ConditionalOnClass({ SecurityFilterChain.class, HttpSecurity.class })
• @ConditionalOnMissingBean({ SecurityFilterChain.class })

So on the reactive stack the back-off only triggers on a missing servlet SecurityFilterChain; a user-defined SecurityWebFilterChain is never considered, and reactiveJwtSecurityFilterChain is still created on top of the user's chain.

Would the team be willing to accept a PR for this? If so, do you have a preferred direction — a dedicated @ConditionalOnDefaultReactiveWebSecurity (checking for a missing SecurityWebFilterChain + reactive classes) used by the reactive auto-configurations, or teaching the existing condition to be stack-aware? Happy to implement it with a regression test once you confirm which approach you'd prefer.

[wilkinsona]

teaching the existing condition to be stack-aware

The existing condition is in a web.servlet package so it should not become stack-aware. It may be possible to deprecate it and introduce a replacement in org.springframework.boot.security.autoconfigure.web although I haven't checked if it'll introduce package tangles. The alternative, as you suggest, is a separate annotation for the reactive stack. If we take the latter approach, we may want to rename @ConditionalOnDefaultWebSecurity to @ConditionalOnDefaultServletWebSecurity to make its purpose more clear. I'll discuss it with the team.

[Akaame]

I was able to reproduce the same behavior in a Spring Boot 4.1 / WebFlux app with multiple custom SecurityWebFilterChain beans.

In our case, Actuator Endpoints under /management/health and /management/prometheus started returning 401 UNAUTHORIZED with WWW-Authenticate: Bearer after the upgrade. I traced it to this issue.

The key point seems to be that ReactiveOAuth2ResourceServerWebSecurityAutoConfiguration is now active even when custom SecurityWebFilterChain beans already exist. In Boot 4.0.6, the reactive resource-server web security config was guarded differently and did not get applied in this case (under ReactiveOAuth2ResourceServerJwkConfiguration).

We confirmed the fallback chain matches the management endpoints and contains authentication filters, which is why the response is WWW-Authenticate: Bearer.

Adding an explicit highest-priority SecurityWebFilterChain for /management/** restores the expected behavior, as it does not let any fallback behavior to trigger.

[blake-bauman]

We are also affected by this. Using @Primary seems to be a workaround for us right now, but we haven't yet done extensive testing to see if there's any edge cases that might be a problem.

[morganaiden186-crypto]

I have also been able to confirm this issue. As noted by other users, the ReactiveOAuth2ResourceServerWebSecurityAutoConfiguration is currently annotated with @ConditionalOnDefaultWebSecurity, which incorrectly targets the servlet stack by checking for a missing SecurityFilterChain bean rather than a SecurityWebFilterChain bean. This results in the reactiveJwtSecurityFilterChain being initialized even when a custom SecurityWebFilterChain is already defined, leading to unexpected 401 UNAUTHORIZED responses on endpoints like Actuator.

…

On Mon, Jun 22, 2026, 5:09 PM blake-bauman ***@***.***> wrote: *blake-bauman* left a comment (spring-projects/spring-boot#50778) <#50778 (comment)> We are also affected by this. Using @primary seems to be a workaround for us right now, but we haven't yet done extensive testing to see if there's any edge cases that might be a problem. — Reply to this email directly, view it on GitHub <#50778?email_source=notifications&email_token=CC237VYEBERC5FSMZ4LNBBL5BGOAPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZXGMYTANZVHAZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4773107582>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CC237VYEUNSALA4RW7DENRL5BGOAPAVCNFSNUABDKJSXA33TNF2G64TZHM3DEOJWG44TAO2JONZXKZJ3GQ3DONRSGIZDQNJTUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CC237VZESOHM3VIKFCT2ZB35BGOAPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZXGMYTANZVHAZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CC237V5ATS5P7LSS5T3VW2D5BGOAPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZXGMYTANZVHAZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>