3 ms·
No, it's a long deprecated JVM that is effectively abandoned. But it's still a good minimum target as all of its successors tend to be backwards compatible. But
by jillesvangurp 2y ago
No, it's a long deprecated JVM that is effectively abandoned. But it's still a good minimum target as all of its successors tend to be backwards compatible. But you'd typically use one of the more recent LTS versions.
Of course there are quite a few crypto libraries out there, including several JWT related ones. A challenge in that space is that there have of course been some platform changes over the years. Not all of the newer algorithms are supported in older JDKs. And some of the alternatives are a bit complicated in terms of dependencies. I've had some issues with some of Google's libraries dragging in everything and the kitchen sink in terms of dependencies and then causing conflicts with my other dependencies when one of those dependencies changes their API.
This one looks like it builds on bouncycastle and not much else. Which explains how it is not really that dependent on what comes with the JDK as bouncy castle provides its own implementations for a lot of the popular crypto stuff.
- tveita 2y agoThis doesn't depend on BouncyCastle AFAICT, by default it uses javax.crypto but you can change it for a BouncyCastle security provider. https://github.com/FusionAuth/fusionauth-jwt/blob/main/src/main/java/io/fusionauth/security/DefaultCryptoProvider.java https://github.com/FusionAuth/fusionauth-jwt/blob/main/src/m...