Error: "alg" parameter "ES256" requires curve "prime256v1"

[kirillgroshkov]

Not a bug report, but a question.

My code started to fail with version 9 because of this error. I've read the Changelog, Migration guide and source code that does this validation and see where it comes from.

I also can see that I can bypass this check with allowInvalidAsymmetricKeyTypes.

What I cannot find information about is what is the implication that I have used "wrong curve" when generating the keys?

In particular, I have used this command before: openssl ecparam -name secp256k1 -genkey -noout -out key.pem. "Correct" command with the "correct" curve looks like this: openssl ecparam -name prime256v1 -genkey -noout -out key.pem.

Are my tokens vulnerable to some attack or something, because I have used the "wrong curve" when generating the keys?

[panva]

Are my tokens vulnerable to some attack or something, because I have used the "wrong curve" when generating the keys?

No, it's just that the designated alg value for your key should be ES256K to be interoperable. The ES256 algorithm requires the use of P-256 EC curve key.

[kirillgroshkov]

Are my tokens vulnerable to some attack or something, because I have used the "wrong curve" when generating the keys?

No, it's just that the designated alg value for your key should be ES256K to be interoperable. The ES256 algorithm requires the use of P-256 EC curve key.

Sorry, but what "interoperable" means?

Right now with the "wrong" key/curve I'm able to successfully verify my own issued keys. Same way, if someone else was using keys with "wrong curve" and share JWT with me - I will be able to successfully verify it (with the public key) (with allowInvalidAsymmetricKeyTypes: true).

What is it that is not "interoperable"?

I'm trying to assess the "severity" of this, is it like "recommendation" (that's fine to ignore), or "warning" (something might break, but what exactly?), or a hard security vulnerability (that my key may be brute-forced or something)?

[kirillgroshkov]

Maybe interoperable means that if I issue a token using this "wrong" combination of alg and key - some other software might fail/refuse to verify my key? (without their own allowInvalidAsymmetricKeyTypes, which I don't control)

That sounds likely.

But then, if I control all "verifiers" of my JWT tokens - I should be "fine" by just doing allowInvalidAsymmetricKeyTypes: true?

[wladpaiva]

ES256K is not a valid algorithm for jsonwebtoken

[panva]

ES256K is not a valid algorithm for jsonwebtoken

ES256K absolutely IS a valid JWS algorithm. Registered in IANA for use in JWS in RFC 8812.

Edit: i see what you mean now, the algorithm isn't supported by this library. That is true. cc @jakelacey2012 this would very simple to add support for. Until then, alternatives are available.

[yaroslav-perec]

I have the same issue, it would be great to have ES256K support in jsonwebtoken

[euberdeveloper]

same issue

[jackson-dean]

+1, would be nice to have support for this without needing to use the awkward allowInvalidAsymmetricKeyTypes flag.