Discussed in #2145
Originally posted by BorisWauters March 18, 2026
Hi all,
I have a question regarding the intended behavior of token validation inside the TokenAuthenticationFetcher class.
Context
TokenAuthenticationFetcher receives a Collection<TokenValidator> and attempts to validate a token found in the request. The current implementation uses a flatMap over the validators, and the first validator that emits a successful validation is used to produce the Authentication.
This has the side effect that multiple validators effectively “race” each other. In our case, this caused issues because we have multiple TokenValidators configured. The first one produces the correct claims and the other one acts as a backup. Due to parallel evaluation, the wrong validator may win the race and produce the authentication result
Our workaround
To prevent the race condition, we implemented a custom version of TokenAuthenticationFetcher where we replaced the standard flatMap with flatMapSequential. This preserves the declared order of the tokenValidators and guarantees deterministic behavior.
Main Question
Is the current parallel behavior of token validation intentional?
More specifically, should the order of the Collection be respected (if the collection has an order)?
Or is the parallel/race behavior the expected and designed behavior?
Would a contribution that enforces sequential validator evaluation (or makes this configurable) be aligned with the project’s goals?
Understanding the intended design would help us know whether we should maintain our custom behavior internally or consider proposing a PR.
Thanks in advance!
Discussed in #2145
Originally posted by BorisWauters March 18, 2026
Hi all,
I have a question regarding the intended behavior of token validation inside the
TokenAuthenticationFetcherclass.Context
TokenAuthenticationFetcher receives a
Collection<TokenValidator>and attempts to validate a token found in the request. The current implementation uses aflatMapover the validators, and the first validator that emits a successful validation is used to produce the Authentication.This has the side effect that multiple validators effectively “race” each other. In our case, this caused issues because we have multiple TokenValidators configured. The first one produces the correct claims and the other one acts as a backup. Due to parallel evaluation, the wrong validator may win the race and produce the authentication result
Our workaround
To prevent the race condition, we implemented a custom version of
TokenAuthenticationFetcherwhere we replaced the standardflatMapwithflatMapSequential. This preserves the declared order of the tokenValidators and guarantees deterministic behavior.Main Question
Is the current parallel behavior of token validation intentional?
More specifically, should the order of the Collection be respected (if the collection has an order)?
Or is the parallel/race behavior the expected and designed behavior?
Would a contribution that enforces sequential validator evaluation (or makes this configurable) be aligned with the project’s goals?
Understanding the intended design would help us know whether we should maintain our custom behavior internally or consider proposing a PR.
Thanks in advance!