JWT signing keys: how issuance and rotation work, and why the alg header can't be trusted

A dev.to post breaks down the mechanics behind JSON Web Token (JWT) security: how signing keys are issued and published, how they should be rotated without invalidating live sessions, and why the algorithm field in a token's header is something verifiers should never take at face value.

What actually authenticates a token

The post opens with an analogy: a forwarded coupon that looks exactly like one your store issued, but is fake. A JWT has the same weakness. A token's authenticity rests not on its contents but on who was able to produce its signature.

A JWT consists of three parts — header, payload and signature. The signature is computed over the header and payload together, so changing a single byte of either makes it stop matching. That integrity check only means something, though, if verification is tied to a key the issuer alone controls.

One key signs, everyone verifies

JWT signing uses asymmetric key pairs. The private key signs tokens and never leaves the issuer; there is exactly one copy. The public key is published so that anyone can check signatures. The asymmetry is the point: a public key can confirm a signature, but it cannot forge one.

Publication happens through a JSON Web Key Set (JWKS) endpoint, typically /.well-known/jwks.. Each key in the set carries a kid (key ID), and every issued token names the kid that signed it. That pairing is how a verifier picks the right public key when more than one is in circulation.

Rotation needs an overlap window

Done naively, key rotation breaks everything at once. The post's guidance is to publish the new public key first and keep the old one listed alongside it until every token signed with the old key has expired. Pull the old key too early and all still-valid tokens fail verification simultaneously — effectively a mass logout.

The kid mechanism is what makes the transition workable: during the overlap, the JWKS serves both keys, and each token indicates which one verifies it.

The alg header is untrusted input

The central warning concerns the alg field in the JWT header. The post advises verifiers to accept signatures only from an explicit algorithm allowlist — RS256 or ES256, for example — and never to let the token itself dictate how it is verified.

Trusting the token's declared algorithm is the root of two classic exploits: the alg=none trick, where a token asserts that no signature is required, and algorithm confusion, where a changed alg value makes a verifier use key material in a way it was never intended to be used. RFC 8725, the JWT Best Current Practices document, calls this out explicitly.

A leaked signing key is a skeleton key

The post cites Storm-0558 as the cautionary tale. In 2023, a signing key that should have been scoped to a single system was obtained by attackers and used to forge tokens, giving them access to email across more than 20 organizations, according to the article, which references Microsoft's 2023 disclosure and a 2024 CISA Cyber Safety Review Board report. One leaked private key compromises everything that trusts it.

Practical checklist

The post condenses its advice into four practices:

• Generate keys as pairs (RSA-2048 or elliptic curve) and keep the private key inside the signing service.
• Publish keys via JWKS with a kid on each, and stamp the kid into every token.
• Rotate with overlap: old and new public keys coexist until old tokens expire.
• Fix the algorithm whitelist, reject "none", and never let a token choose its own verification method.

Why it matters

JWTs sit under the authentication path of a large share of modern web applications, and their failure modes are quiet. A botched rotation logs everyone out at once; a trusted alg header or a leaked private key can hand an attacker account access with no visible breakage. The fixes are inexpensive — pinning an algorithm list is a small amount of configuration — but they only get applied when developers internalise the post's core point: everything inside a token, header included, is untrusted input until its signature checks out against a key and algorithm the verifier chose itself.