Async API for JwtParser and JwtBuilder?

[mnylensc]

Hey! Thought to ask - has there been any discussions in the past about providing asynchronous API for JwtParser/JwtBuilder?

The use case would be to allow offloading any key operations to external service, such as AWS KMS, in an otherwise asynchronous server. The benefit of using services like these is that they use hardware security modules, where the keys are not extractable quite as easily. Things like supply chain attacks happen, so having the keys sitting in JVM memory or passed in via environment variables is not great in high security contexts.

Currently one can override the implementation of for example the ES256 SignatureAlgorithm with a version where digest(SecureRequest<InputStream, PrivateKey>) and verify(VerifySecureDigestRequest<PublicKey>) methods do a network call to an external service. However, this must be done via synchronous API.

Using the current API from asynchronous code with a SignatureAlgorithm implementation like this will require the caller to carefully wrap any JwtParser#parseSignedClaims and JwtBuilder#compact calls with, for example, CompletableFuture.supplyAsync(() -> parser.parseSignedClaims(), executor) to avoid blocking the event loop.

This brings some added complexity in having to manage yet another thread pool for these operations when everything could just happen on the existing Netty event loop if an asynchronous API was provided.

Would it be possible for there to be AsyncJwtParser and AsyncJwtBuilder where the parseSignedClaims() would return CompletableFuture<Jws<Claims>> and compact() would return CompletableFuture<String>? This would then of course need some changes to the signature algorithm interfaces as well. Likely the same default implementations could implement both synchronous and asynchronous interfaces, where the asynchronous one would just be wrapped in CompletableFuture.

Best Regards,
Mikko Nylén

[lhazlewood]

Hi @mnylensc !

Usually there is no need to override JJWT SignatureAlgorithm implementations if you use a JCE Provider for an HSM, e.g. see https://docs.aws.amazon.com/cloudhsm/latest/userguide/java-library.html and https://github.com/jwtk/jjwt?tab=readme-ov-file#provider-constrained-keys. This ensures the key and computation do not need to be used within the Java process/memory.

As for an async API, we haven't looked into this, nor has anyone requested it yet in the 10 year history of the project, so, just in all honesty and transparency, it wouldn't exactly be high on our implementation/feature list when CompletableFuture.supplyAsync alternatives can assist.

This is just my own opinion, but the (often very challenging) mental context shift for developers, quality error handling, and other challenges of directly using async APIs within Java code make it a very difficult landscape to navigate for most programming teams. And except in some very specific scenarios, JDK 19+ Virtual Threads may eliminate the need for developers to go down the async mental rabbit hole, further reducing any need to use Future-oriented programming.

I bring this up not to say that we wouldn't implement an async API, just that the likely need of it for most Java teams seems to be diminishing over time.

For JJWT specifically, a good bit of work would be required to see the full scope of how this could be achieved - key lookup, as well as parsing, and compact()tion would likely all need to use async (and async I/O) APIs, async JSON library calls, etc, and it's not clear at all how much that would force underlying APIs (algorithm implementations) to change.

My personal opinion is that I'd like to see how many people that use JJWT want something like this before we undertake such an effort. It's non-trivial, so the 'juice would need to be worth the squeeze' in my opinion. And that also needs to take into consideration maintaining these APIs over a very long period of time, which is a lot to ask if the demand isn't high.

Just my two cents!

[mnylensc]

Thank you for the thorough reply. I agree that if it hasn't been requested before in ten years, there's likely not much demand for it, or people have found suitable workarounds already, like we have with the CompletableFuture.supplyAsync(). This thread was more of a discussion opener to gauge if there is any interest for something like this.

I might also have failed to understand how deep the changes would need to go, and as you mention, definitely key lookup is one part where someone might want to also use async lookup if it was an option. I'm not sure if the JSON library calls would need to be async though, but I guess someone might have a need for streaming a large chunks of JSON. It's a good question where to draw the line.

As for the JCE Provider, it's definitely a better option than rolling your own SignatureAlgorithm if whatever service you use happens to have a JCE Provider. AWS KMS doesn't, and although there is sample code that you can copy to your project available, it's somewhat unnecessarily complex when you don't need it for other crypto operations.

[lhazlewood]

Thanks @mnylensc for your thoughtful reply as well! Based on the 'wait and see' consensus we seem to be developing, I'll close this discussion in the meantime, and leave comments available for further discussion in case anyone would like to chime in. I'm definitely happy to revisit this if there's enough interest!