You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
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.
alg
property specifying the algorithmcrv
propertyThis 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?
The text was updated successfully, but these errors were encountered: