I reviewed the Spring Security contributing guidelines and code of conduct before opening this. I’m aiming to describe a concrete API gap and a proposed extension point that seems consistent with existing Spring Authorization Server patterns.

Expected Behavior

OAuth2TokenExchangeAuthenticationProvider should expose a fine-grained validation hook, similar to the validator callbacks already available on some other built-in authorization server providers.

That would allow applications to enforce token-exchange-specific policy during authentication, before token generation begins, without needing to replace or wrap the framework provider wiring.

A possible shape could be something like:

void setAuthenticationValidator(Consumer<OAuth2TokenExchangeAuthenticationContext> authenticationValidator)

or another context type that best fits the token exchange flow.

Current Behavior

For token exchange, there does not appear to be a comparable validator callback on OAuth2TokenExchangeAuthenticationProvider.

As a result, server-specific policy validation that belongs in the authentication phase, such as:

• validating resolved subject_token claims
• enforcing resource indicator requirements beyond RFC-minimum parsing
• applying audience or delegation policy based on resolved authorization state

typically requires customizing the token endpoint provider list and wrapping or replacing the built-in OAuth2TokenExchangeAuthenticationProvider.

That works, but it is more brittle than the validator pattern used elsewhere, and it can require duplicate authorization lookups just to validate before delegating back to the framework provider.

Context

This came up while implementing token exchange policy that I would prefer live in authentication policy code.

I’m aware of the existing token endpoint customization mechanisms via OAuth2TokenEndpointConfigurer.authenticationProvider(...) / authenticationProviders(...), and that is the current workaround. However, compared to the existing validator callback pattern on other providers, it is a relatively coarse extension point for this use case.

For comparison, other built-in providers already expose narrower validator hooks, for example:

• OAuth2AuthorizationCodeRequestAuthenticationProvider#setAuthenticationValidator(...)
• OAuth2ClientCredentialsAuthenticationProvider#setAuthenticationValidator(...)

Given those existing APIs, would you consider adding a similar validator hook for token exchange as well?

If this would be accepted, I’d be happy to put together a PR.

Acknowledgement: Codex helped draft this issue.