Generate algorithm in jwk

[spbooth]

I'm trying to generate a PublicJWK with the algorithm field set to the same algorithm that the library will auto-select when signing a JWT with the corresponding private key. However the only accessible method I can find io.jsonwebtoken.SignatureAlgorithm.forSigningKey(Key) is from a deprecated class. It seems wrong to duplicate the algorithm selection logic if I let the library pick when generating JWTs.

Would it make sense for DynamicJwkBuilder to have a algorithmFromSigningKey(Key) method, or am I missing an easy way to do this?

I don't see a simple way of generating the algorithm automatically because you need the private key to determine the key bit-count and as its a PublicJWK it only contains the public key. Obviously this is only needed if you are going to let the algorithm auto-select when generating JWTs.

[bdemers]

@spbooth Does this section of the docs help: https://github.com/jwtk/jjwt?tab=readme-ov-file#creating-safe-keys
If so, maybe we need to update the deprecation tag to point to these docs 🤔

[spbooth]

No thats how to create the cryptographic key, I'm trying to generate a JWK json representation of a key I already have.
https://github.com/jwtk/jjwt?tab=readme-ov-file#json-web-keys-jwks

For example

               String alg = io.jsonwebtoken.SignatureAlgorithm.forSigningKey(getPrivateKey(kid)).toString();
		X509Certificate cert = getCertificate(kid);
		if( cert != null) {
			List<X509Certificate> l = new LinkedList<>();
			l.add(cert);
			PublicKey publicKey = cert.getPublicKey();
			return Jwks.builder()
                                  .key(publicKey)
                                  .id(kid)
                                  .publicKeyUse("sig")
                                  .algorithm(alg)
                                  .x509Chain(l)
                                  .x509Sha1Thumbprint(true)
                                  .build();
		}

but I'm having to use a deprecated class to calculate the signing algorithm from the private key

[spbooth]

There is findByKey(Key) in io.jsonwebtoken.impl.security.DefaultMacAlgorithm but thats in the implementation so not visible hence my suggestion to add a method to the builder that takes the key.

[bdemers]

Ahh, sorry, you said, jwk, I misread that.

I'll let @lhazlewood chime in on this one.

[lhazlewood]

The JwkBuilder's .signWith(Key) is just a convenience with JJWT-specific heuristics that attempt to find the strongest algorithm for a given key. It's really just meant as a 'I just want the strongest, I don't want to have to look up specifics, just sign please' convenience.

But your use case is a little more targeted and specific beyond this convenience, so it probably makes sense to specifically choose the algorithm explicitly and use the .signWith(Key, SecureDigestAlgorithm) variant, and then set that same algorithm value on the corresponding PublicJwk being built. At least using the current API.

Thinking about new additions or conveniences like a new algorithmFromSigningKey(Key) method, I do see value in that, but I wonder if there might be a better approach:

A JWK alg value is meant to constrain how the key should be used. For example, a 2048-bit RSA key can generally be used with any of the RS256, RS384, RS512, PS256, PS384, and PS512 algorithms, but setting its corresponding JWK's alg value to PS512 indicates that it should ideally only be used with that algorithm.

Based on this, it seems like there should probably be .signWith(ConfidentialJwk) method that accepts a (new interface) ConfidentialJwk that both PrivateJwk and SecretJwk extend. The method implementation can inspect that JWK's alg value, and choose the associated algorithm accordingly.

If the argument is a PrivatelJwk, its .toPublicJwk() method would report the same alg value, keeping everything consistent.

My thinking is that two separate .signWith(Key) and .algorithmFromSigningKey(Key) methods, while producing the same values, allows for disjoint state if one is called and the other is not. By having it represented in a ConfidentialJwk instance, the value is consistent and shared during both signing and public JWK creation, and less opportunity for having the two scenarios reflect different values.

Thoughts?

[spbooth]

That makes perfect sense. If I'm not explicitly constraining the signature algorithm in my application configuration then omit the alg constraint on the JWK.
To be honest it is used so consistently used I'd forgotten it was technically optional. Actually so is "kid" when there is only one key but I've hit problems with that before now.