Skip to content

Restore JWT precedence when opaque token is also configured - #52311

Open
beyondwin wants to merge 1 commit into
spring-projects:4.1.xfrom
beyondwin:oauth2-resource-server-jwt-and-opaque
Open

beyondwin wants to merge 1 commit into
spring-projects:4.1.xfrom
beyondwin:oauth2-resource-server-jwt-and-opaque

Conversation

@beyondwin

Copy link
Copy Markdown

With both spring.security.oauth2.resourceserver.jwt.jwk-set-uri and spring.security.oauth2.resourceserver.opaquetoken.introspection-uri set and no user-defined filter chain, 4.0.x uses JWT, as it has since 2.3 (#19426). With 4.1.0 and 4.1.1, a servlet application fails to start:

org.springframework.security.web.UnreachableFilterChainException: A filter chain that matches any request [DefaultSecurityFilterChain defined as 'jwtSecurityFilterChain' ...] has already been configured, which means that this filter chain [DefaultSecurityFilterChain defined as 'opaqueTokenSecurityFilterChain' ...] will never get invoked.

Since #43978 both chains are defined in OAuth2ResourceServerWebSecurityAutoConfiguration, and the test assertion that JWT is used was dropped in the same change. A reactive application gets an opaque token chain that is never used.

This makes the opaque token filter chains conditional on a missing JwtDecoder / ReactiveJwtDecoder. The decoder and introspector beans are unaffected. The new tests fail without the change.

Prior to 4.1, when both a JwtDecoder and an OpaqueTokenIntrospector
were available, the resource server's opaque token configuration backed
off and only the JWT security filter chain was defined.

Since the filter chains were moved to
OAuth2ResourceServerWebSecurityAutoConfiguration, both are defined. A
servlet application fails to start with an
UnreachableFilterChainException and a reactive application has an
opaque token chain that is never used.

This commit makes the opaque token filter chain conditional on a missing
JwtDecoder (ReactiveJwtDecoder for reactive) so that JWT is used, as
before.

Signed-off-by: WooSeung Kim <wooseung.dev@gmail.com>
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue that has not yet been triaged. Contributions will not be accepted. label Oct 20, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: waiting-for-triage An issue that has not yet been triaged. Contributions will not be accepted.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants