jwtk/jjwt

Add io.jsonwebtoken.SignatureAlgorithm#assertValidSigningKey in new class

milazzo-g opened this issue · 1 comments

milazzo-g commented

Hi, I see that io.jsonwebtoken.SignatureAlgorithm is deprecated in 0.12.3 and there's no assertValidSigningKey method (or similar) in Jwts.SIG.*

Could you add this method into another class?

KR.

lhazlewood commented

Hi @giuseppe-milazzo, that method is deprecated because ultimately each MAC or Signature Algorithm is responsible for determining what is valid or not based on its specific implementation requirements.

Starting in JJWT 0.12.0, these algorithms are pluggable and/or customizable, so it's not possible for all algorithm requirements - especially for custom algorithms - to be embedded in a single static method or Enum.

Another way of saying this is that any time an algorithm was added or removed, that static method would need to be updated, which is a yellow flag/warning that the previous code was too tightly coupled.

So, now that the algorithm implementation is itself responsible to validate keys used with it, it's no longer necessary to 'force' this to be publicly exposed. That is, nothing in JJWTs higher APIs require this method, so it would impose unnecessary implementation (and support) requirements on higher-level classes, e.g. in the Jwts.SIG class.

Additionally, even if we did add such a method somewhere, it wouldn't work for any custom or restricted algorithms. That is, either of the following cases are possible:

  • A custom (non standard) SignatureAlgorithm or MacAlgorithm implementation is added to a JwtBuilder and JwtParser's total set of supported algorithms.

  • One or more RFC-standard SignatureAlgorithm or MacAlgorithm instances are removed from a JwtBuilder or JwtParser's total set of supported algorithms, because the application wants to limit what algorithms are available to enforce higher strength security requirements.

In either of these two scenarios, the previous static (Enum) method couldn't 'know' what algorithms are in use or allowed by the application to perform validation.

Anyway, those are the reasons for the changes. Could you please let us know why this may not be sufficient for your needs?

What is the desired/expected behavior and/or use case for your application?

Thanks!