HS256 vs RS256 vs ES256: JWT Signing Algorithms

With HS256 there is one key. The issuer computes an HMAC over the token's header and payload with a secret, and the verifier recomputes it with the same secret. Anything that can check a token therefore holds the key that can forge one. That is acceptable when the issuer and the verifier are the same service, and a risk when the secret has to be copied to several services.

With RS256 and ES256 there are two keys. The issuer signs with a private key that never leaves it, and anyone can verify with the matching public key. Verifiers cannot mint tokens, and the public key can be published.

The signature is the third part of a JWT, so its size is added to every request that carries the token. An HMAC signature is as long as its hash output, an RSA signature is as long as the key, and an ECDSA signature is two integers the size of the curve.

RFC 7518 says an HS256 key MUST be at least as long as the hash output, 256 bits, and that RSA keys MUST be 2048 bits or larger. ES256 always uses the P-256 curve.

For HS256 the quality of the secret matters as much as its length. RFC 8725, the JWT best-practices document, says human-memorizable passwords MUST NOT be used directly as an HS256 key: once an attacker has one token, a weak secret can be guessed offline. Use at least 32 bytes from a cryptographically secure random source.

Libraries do not always enforce these rules. In the same test, jose 6.2.3 refused an RSA key under 2048 bits but signed an HS256 token with an 8-byte secret.

A JWT names its own signing algorithm in the alg header, and RFC 8725 describes two attacks that abuse this. In the first, an attacker changes alg to none, and a library that trusts the header accepts the token without checking any signature. In the second, a token meant for RS256 is relabelled HS256, and a library verifies it with HMAC using the RSA public key, which is not secret, as the shared secret.

The fix is the same for both: the verifier decides which algorithms it accepts instead of reading that from the token. RFC 8725 says libraries MUST let the caller specify a supported set of algorithms, and that each key MUST be used with exactly one algorithm.

It is smaller. In the table above an ES256 token is 226 characters where the RS256 one is 482, and the public key is about a third of the size. RFC 7518 also marks ES256 as "Recommended+" where RS256 is "Recommended".

ES256 has one requirement RS256 does not. ECDSA needs a unique random value for every signature, and RFC 8725 warns that if those values are predictable the private key may be recoverable. It says libraries SHOULD use the deterministic method in RFC 6979. That is the library's job, not something you set per token.

RS256 remains a reasonable choice when a verifier you do not control only supports RSA. RFC 7518 defines both.

Use HS256 when one service both issues and verifies its tokens and the secret is long, random and stored in one place. Use an asymmetric algorithm as soon as a second party needs to verify tokens, so that verifying does not require the power to issue.

Between the two, choose ES256 for smaller tokens and keys, and RS256 where the systems that verify your tokens require RSA. Whichever you choose, configure the verifier with an explicit list of accepted algorithms.