I'm implementing JWT authentication for a new web service and am unsure which asymmetric algorithm to choose. I've searched around and haven't found any consensus or clear recommendations. According to the PyJWT docs there are a few different algorithms to choose from.

I'd like to use an algorithm that is secure (obviously), has low overhead and is future proof. Which algorithm fits the bill?


RFC7518 lists the algorithms and whether they are required, recommended or optional for a JWT library. This can help you choose an algorithm that has implementations in other libraries, for interoperability purposes.

From a security perspective, there are these options:

  • RSASSA vs. ECDSA. ECDSA use elliptic curves, and some people think these are more secure than RSA. They are also faster and allow you to use smaller keys.
  • SHA256, SHA384, SHA512. You could say more is better, but since SHA256 is already impossible to brute-force it makes little sense to use more bits.
  • PKCS1-v1_5 vs. PSS. PSS has some security advantages, but is more complex than PKCS1, possibly making implementation errors more likely.

All of these options are secure and the differences are largely theoretical. I would probably recommend ECDSA using P-256 and SHA-256 (alg parameter value ES256 in the spec), since

  • that is likely to be implemented in a lot of JWT implementations, according to the RFC,
  • it uses elliptic curves which have some slight security and performance benefits.

The other answer mentioned quantum computers. We don't have viable quantum computers right now, but if they existed they could easily break all of the possible JWT algorithms. So from a post-quantum viewpoint it doesn't matter which one you choose, since all are equally insecure.

See also:

| improve this answer | |
  • 1
    Thanks for your answer. Just a question regarding the performance of RSA vs ECDSA, you mentioned that ECDSA is faster (I'm assuming you mean that it's more efficient and scales better), but I found this other answer that says that the verification performance of ECDSA is not as good as RSA: crypto.stackexchange.com/a/3218. Does this in fact mean that using RSA would lead to better performance when signing and verifying tokens? – user3607758 Oct 1 '18 at 8:23

RSA is often the algorithm of choice, as it is now rather old and survived going through a lot of scrutiny. You can't go wrong chosing it. The 256 variant is good enough IMO as SHA256 is nowhere near being broken.

If you care about the size of the message, which you likely do in JWT, you may want to use ECC. It allows for significantly shorter signatures while being as secure as RSA in theory. In practice, the problem is in implementation. There have been spiked curves in the past and a lot of problems with implementation such as off-curve attacks. It is more likely for ECC to have mistakes in implementation IMO.

The PS algorithms are based on RSA but apparently are modified to have a reduction proof. I would not give too much stock in the proof and as it is relatively new and more complicated, implementations may have problems. I would not choose these.

So in the end, I would chooose one of these two depending on what level of security you need. ES256 is probably the beter choice for most webapps.

PS: Either way, you should obviously make sure your jwt library is being updated in a timely manner in case there are security related bugfixes.

| improve this answer | |
  • What is a "spiked curve" or an "off-curve attack"? Wikipedia's elliptic curve cryptography article neither contains the word "spiked" nor "off". – Luc Oct 31 '18 at 9:05
  • 1
    @Luc They are attacks related to how exactly these algorithms work. Elliptic curve algorithms uses math based on points on a specific elliptic curve. An off-curve attack is an attack where the attacker chooses such an input, that the points are not on the curve. If he is able to do so (the library does not check and refuse such input), then the attacker is able to use this to break the security in some ways. Spiked curve attack is an attack, where the creator of the curve deliberately chooses a curve, that can be broken. It is strongly suspected NIST curves are spiked by the NSA. – Peter Harmann Oct 31 '18 at 11:16
  • Thanks! It's hard to find anything about off-curve attacks, though. The only paper that seems remotely relevant is this one, but the vulns presented there (Ctrl+F for CVE) don't seem to be what you described. Do you have an example CVE or other link? – Luc Oct 31 '18 at 12:39
  • @Luc honestly, no. It is an example our tutor gave at a lecture, but I did not hear about a real world exploitation of this. Anyway, it was just an example of possible implementation mistake (not checking input). The larger point is, that RSA by being older would generally have fewer mistakes in implementations, as people got more used to it and everything that could have been done wrong was at some point. – Peter Harmann Oct 31 '18 at 19:57

You should implement your software this way, that you can easily exchange the signing algorithm. Hopefully pyjwt will also support new algorithms, when the are around.

Given that several people are afraid of quantum computers, which are said to be able to break RSA one day, since prime factors generation can be easily parallalized you should consider using an eliptic curve algorithm.

But as the paragraph below states... using a "good" algorithm is usually a bad idea, if it is used the wrong way.

| improve this answer | |
  • 2
    Elliptic curves are also insecure against quantum computers, just like RSA. – Sjoerd Oct 1 '18 at 6:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.