Spring Security Reactive oauth2 resource server - reactive authentication manager's cahing

Current Behavior

With Spring Security 5.3 one can configure oauth2 resource server to support multiple tenant's. For this purpose class JwtIssuerReactiveAuthenticationManagerResolver.class exist's. It contain's subclass TrustedIssuerJwtAuthenticationManagerResolver.class with method resolve(String issuer) to store reactive authentication managers identified by given issuer URL parsed from JWT access token. This reactive authentication managers are currently stored inside cached monad Mono.

Expected Behavior

Caching of reactive authentication manager's (Nimbus decoder's in this case) should be limited to some meaningful time or user should decide for how long reactive authentication manager should be cached. Since issuer JWK keys might change over time, "hot" caching (for infinite time) is not appropriate in this case and cached reactive authentication manager's must be recomputed repeatedly so new JWK keys will be used. We can use overloaded method cache(Duration ttl), instead of "hot" caching with cache() method, on Mono instances to ensure reloading of new JWK keys and it should be also easy to be done in the way that user's of the framework might choose for how long caching should last.

Context

I am implementing my custom ReactiveAuthenticationManagerResolver since i want to pick JWK URI's according to value provided in request header's and therefore this issue is currently not problem for me but might be a problem for other user's.

Comment From: jzheaux

Thanks for the suggestion, @ndopj.

Since issuer JWK keys might change over time,

Just to clarify this point, NimbusReactiveJwtDecoder already caches the keys for a finite period of time.

Because the resolver has an unchanging list of issuers, I'm not sure what invalidating the resolver cache would accomplish more than NimbusReactiveJwtDecoders ttl already does.

Can you elaborate on what you are trying to accomplish?

Comment From: ndopj

Well i didn't notice NimbusReactiveJwtDecoder already does this job despite the fact i went trough the implementation finding for such a feature. This issue is thus solved and i am closing it. Thank you for your time.

Comment From: hkellysalesforce

@jzheaux Do you have any docs around how NimbusReactiveJwtDecoder how it caches or how the cache period can be configured? I found the Javadoc but it doesn't mention caching anywhere.

From poking around, my guess is that the cache is implemented here and actually caches the JWK indefinitely (until it fails) using Mono. I'm guessing this cache is internal to the decoder instance itself, so if you declare a new decoder for each JWT then it would not benefit from the cache and pull the JWK each time. Is that right?