PS256 is not the recommended one by rfc7518
sherlock1982 opened this issue · comments
By default my generated token has alg header "PS256".
According to
https://datatracker.ietf.org/doc/html/rfc7518
ES256: Recommended+
RS256: Recommended
Looks like it should be ES256 by default?
P.S. I might not fully understand what "Recommended" is. Looks like it means "recommended for implementations". Nevertheless default algorithm should not be "optional for implementation" I think.
Generally I'm unable to understand from the RFC which are more secure/less secure.
Hi @sherlock1982 good point.
In the past, we set ES256 as the default, but the issue is that JWE does not accept Elliptic Curves, so using ECDsa by default limits the scope of the library's use. And that wasn't even our biggest problem.
Not too long ago, we had integration issues with Nodejs because many components did not accept ECDsa for token validation. So, the decision was made to make RSA the default, with the option to switch to others. In such cases, who do this needs to be aware of these potential problems.
Components that did not accept ES256 (I don't know if this is still a limitation):
https://github.com/okta/okta-jwt-verifier-js
https://github.com/auth0/node-jwks-rsa
https://github.com/auth0/node-jsonwebtoken
P.S. I might not fully understand what "Recommended" is. Looks like it means "recommended for implementations". Nevertheless default algorithm should not be "optional for implementation" I think.
Generally I'm unable to understand from the RFC which are more secure/less secure.
I assume they don't specify which is better because it depends on each scenario.
Although Elliptic Curves are fast for validation, they are slower than RSA for digital signatures. Additionally, they can't be used with JWE. Even though there's a '+' in the RFC, I understand that its usage is more conditioned to the use-case of each project. Generally speaking, developers who use these kind of components don't have enough knowledge to decide which alg to use. That's why we chose RS256 for greater compatibility without necessarily compromising security.
Ok thanks for the explanation!
For my case I think i will still stick to HS256 cause producer/validator is the same app in the end.
Will use Security.Jwt for it's rotation capabilities :-)