Support non-blocking keylocators #1026
Description
Is your feature request related to a problem? Please describe.
We had an issue in one of our applications where a lot of concurrent requests lead to thread starvation every time the cached signature JWK was updated (we get the signature JWK from an OAuth2 JWKS endpoint and cache it in-memory for
There's things we can do on our end to address this issue, as our code is also somewhat at fault here. But it leads me to think that the jjwt API is also somewhat preventing a clean solution due to its blocking implementation, especially when it comes to the KeyLocator, which by definition might need to do blocking I/O (like getting the JWK from a remote service)
Describe the solution you'd like
It should be possible to provide some form of KeyLocator that implements fetching the key in a non-blocking manner., something like this:
public interface AsyncLocator<T> {
CompletionStage<T> locate(Header header);
}Describe alternatives you've considered
We can currently live with the parser being blocking, we try to limit blocking code as much as possible in the KeyLocator by heavily relying on caching and revisiting our dispatcher configurations. But since most of our code in this project is leveraging non-blocking APIs, the blocking JWT parsing via jjwt is standing out a bit.