Add support for EDDSA about fusionauth-jwt HOT 12 OPEN

I would vote for either of the first options.
There are quite a few JWT libraries for Java, but none that I can find with full support for EdDSA and most are resolutely trying to support JDK 8, which is holding them back from supporting it.
Great to see movement on this.

from fusionauth-jwt.

Thanks for the feedback @Yaytay.

from fusionauth-jwt.

Yeah one of the reasons I picked this library is it seems updated, just the right size code base wise, and well supported.

Since you guys are newer smaller library (so hopefully less angry users on JDK upgrade) maybe we can get JDK 17 baseline and EdDSA support soon?

from fusionauth-jwt.

RFC specifying this: https://tools.ietf.org/html/rfc8037

from fusionauth-jwt.

Java supports EdDSA: https://openjdk.java.net/jeps/339

from fusionauth-jwt.

I could add support for this in the library, but this feature was included in Java 15. Ideally I'd only anchor to Java LTS releases.

So I could:

• Increase the min. requirement from Java 8 to Java 17
• Build a separate jar named fusionauth-jwt-eddsa that requires Java 17, but the base library still remains at 8
• I may be able to implement it w/out binding to any new interfaces and just use reflection. If this works, then this algorithm would only work when running on >= Java 17

from fusionauth-jwt.

Hacking a bit on this branch

• https://github.com/FusionAuth/fusionauth-jwt/tree/EdDSA

from fusionauth-jwt.

See also

• #32

from fusionauth-jwt.

One technique to the whole Java 17 issue that I have used several times is to use the ServiceLoader pattern. Write the ED part as a separate jar and if its included on the classpath it automatically is available. This is sort of like the reflection changes @robotdan talked about but it is far more canonical than a reflection hack (as well as Graal native friendly).

I was looking at @robotdan changes to make EdDSA support work to see what is required to add a new algorithm and it appears the way things are currently designed with heavy use of enums that it would be a lot of work to add pluggable algorithms (and would probably require a major version change).

Most of the problem is the enums but there are also classes that are essentially a merge of all the algorithms (JSONWebKey iirc).

It is a shame though because I see value in having all the algorithms as modules (e.g. separate jars with a MET-INF/services registration) as folks could choose only the algorithms they want and say to their security team that there is no way they accidentally generate with some other algorithm... well maybe that is a dumb reason but it would make the deployed size every so slightly smaller.

from fusionauth-jwt.

If I can find an evening to hack on the branch I started, I may be able to finish it.

from fusionauth-jwt.

Taking a stab at a major version release of this library to make it more extendable, and taking my EdDSA branch and moving it to a new repo to prove the theory.

• https://github.com/FusionAuth/fusionauth-jwt/tree/degroff/extendable
• https://github.com/FusionAuth/fusionauth-jwt-eddsa
• https://github.com/FusionAuth/fusionauth-jwt-unsecured

If it all holds together, I should get this out soon.

from fusionauth-jwt.

Getting closer. I re-worked the branch and use the java.util.ServiceLoader which is a bit cleaner than what I was doing prior.

from fusionauth-jwt.