Resolving algorithms from JWK when not explicitly specified

[MatteoPierro]

Currently, JWT.decode always expects to have the algorithms provided by the client.
When using JWKs this information can be redundant since supported algorithms can be resolved from the provided keys.

• RSA and HMAC keys can have the alg property specifying the algorithm
• EC keys this information can be resolved from the crv property

This kind of resolve will be triggered only if the client is not explicitly specifying the algorithms (the current behavior).

Do you see any security issues resolving the algorithm from the JWK?

[herkusas]

@anakinj Would it be possible to implement this?

I can't find a good reason why not to.

People are having issues when they are verifying some tokens from a third party and then the third party suddenly changes the algorithm they use, for example, they are moving from the RS256 algorithm to the PS256 (If the third party wants to comply with financial grade API then they should use ES256 or PS256. And if they switch from RS256 -> KABOOM! Nothing works).

I agree that allowed algorithms are nice, but it's not always needed, if you trust the key from JWKS, you should trust the algorithm as well.

There are ways to iterate through JWKS and provide algorithms of the keys it holds, but why?

[anakinj]

Support for this functionality added in v3.1