Detecting JCA family name of a given algorithm about jjwt

[lhazlewood]

The previous getFamilyName() was mostly an implementation detail that ideally shouldn't have been exposed to application developers.

The latest JJWT API doesn't need getFamilyName() anywhere - i.e. it's not required by any of the JwtBuilder or JwtParser usage scenarios, so it doesn't (initially) make sense to add it to the public API. In other words, adding things to the public API that aren't used anywhere by the public API add implementation and long term maintenance burden on something that isn't used within JJWT's codebase.

Out of curiosity, what is the JWT use case where this is required?

[OriSchmitz]

Out of curiosity, what is the JWT use case where this is required?

I have cases where my keys are stored as strings, and need to produce instances of Key by the algorithm:

                    String key = "some key retrieved by 'kid'";
                    SignatureAlgorithm algorithm = SignatureAlgorithm.forName(header.getAlgorithm());
                    if (algorithm.isHmac()) {
                        // Hmac key
                        return Keys.hmacShaKeyFor(Base64.getEncoder().encode(key.getBytes()));
                    } else {
                        // Public/Private key pair
                        return KeyFactory.getInstance(algorithm.getFamilyName()).generatePublic(new X509EncodedKeySpec(Base64.getDecoder().decode(key.getBytes())));
                    }

If there's another workaround for that it'd help as well, that is constructing a Key from a string based on the expected algorithm.

[lhazlewood]

Ah, I see now. Because key material can be used for different algorithms, and in cryptographic contexts, you rarely want to use a key across different cryptographic operations (i.e. you ideally shouldn't use a signature key for encryption and vice versa), usually the key type/algorithms/purpose is serialized/represented with the key material. This allows deserialization to ensure that the key is represented and used for its intended purpose.

Additionally, the code shown above is a security risk: one should not rely on the incoming JWT to 'tell' you what your serialized key should be used for - a malicious JWT can indicate a different algorithm, and the code could blindly create the key based on what the JWT says instead of what the serialized key is actually intended for.

Ideally your keys, when stored as strings, should also store the keys' algorithm and allowed usages, and ensure that the key is being used as you intend it, not what the JWT indicates.

One potential solution is you could concatenate this information with your key string before saving. Then, when reading the key, construct the key based on the concatenated information.

Another (better?) solution is to represent your key(s) as JWKs, which are just JSON strings at the end of the day, because JWKs represent all of this information already: https://github.com/jwtk/jjwt#json-web-keys-jwks

But be careful of course: any private or secret JWK still represents sensitive information, so those String(s) should be encrypted before stored (e.g. in a database or on disk).

[lhazlewood]

Since there hasn't been follow-up on this for the last few weeks, I'm closing it since it doesn't appear that this needs to be a change in the JJWT codebase. Happy to discuss further if you feel otherwise!