Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolving algorithms from JWK when not explicitly specified #400

Open
MatteoPierro opened this issue Dec 30, 2020 · 1 comment
Open

Resolving algorithms from JWK when not explicitly specified #400

MatteoPierro opened this issue Dec 30, 2020 · 1 comment

Comments

@MatteoPierro
Copy link
Contributor

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
Copy link

@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).

image

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants