DEV Community: Autional

How JWT Signing Keys Are Issued and Rotated (and Why 'alg' Deserves Distrust)

Autional — Fri, 09 Oct 2026 05:01:54 +0000

Someone forwards a coupon that looks like it came from your store — same name, same styling. It’s fake. A JWT has the exact same problem: what makes it real is not what it says, but who could produce its signature.

A JWT is three parts

header.payload.signature

The signature is computed over header + payload. Change a single byte and it no longer matches — that’s the whole point.

Keys are a pair

Private key — used to sign. There is exactly one, and it never leaves the issuer.
Public key — used to verify. It’s published, so anyone can check a signature.

So: only the issuer can produce a signature, but everyone can verify one. The public key can verify — it cannot forge.

Publishing keys: JWKS + `kid`

Verifiers fetch the public keys from a JWKS endpoint (/.well-known/jwks.json). Each key carries a kid (key id), and each issued token declares which kid signed it. That’s how a verifier picks the right public key.

Rotation: overlap or you break everything

When you rotate keys, publish the new public key first and keep the old one alongside until every token signed by the old key has expired. Pull the old key too early and every live token becomes invalid at once.

Verify with a fixed algorithm — never trust the token

Only accept signatures from an explicit algorithm allowlist (e.g. RS256/ES256). Never trust the token’s own alg header — this is the classic alg=none and algorithm-confusion footgun. RFC 8725 (JWT Best Current Practices) is explicit about it.

A real case: Storm-0558 (2023)

In 2023, a signing key that should have been scoped to one system was obtained and used to forge tokens, letting attackers read email across 20+ organizations. A single leaked signing key is a skeleton key for everything that trusts it.

Engineering practice

Generate keys as a pair (RSA-2048 / EC). The private key never leaves the service.
Publish JWKS with a kid on each key; include the kid in every token.
Rotate with overlap: new + old public keys published together until old tokens expire.
Fix the algorithm whitelist; reject none; don’t let the token tell you how to verify it.

These practices come from building Autional, an open-core identity layer — https://www.autional.com

Reference: RFC 7515 (JWS), RFC 7517 (JWK/JWKS), RFC 7518 (JWA), RFC 7519 (JWT), RFC 8725 (JWT BCP); Storm-0558 (Microsoft disclosure 2023 / CISA CSRB report 2024).

Base64 Is Not Encryption: Encoding, Hashing, Encryption and Signing Are Four Different Tools

Autional — Fri, 09 Oct 2026 04:54:52 +0000

“I turned it into gibberish, so it’s encrypted now” — if that sounds familiar, it’s probably Base64. Anyone can reverse it, no key required. Encoding, hashing, encryption and signing are four different tools that get mixed up constantly. Use the wrong one and you leak.

The four tools

Encoding (Base64) — change the representation so binary data can travel through text-only channels. Provides zero secrecy.
Hashing (SHA-256, SM3) — a one-way fingerprint. Verifies integrity and stores passwords. You can’t reverse it.
Encryption (AES-256-GCM, SM4-GCM) — a lock. You need the key to read it back.
Signing (Ed25519, RSA) — a seal. Proves who sent it and that it wasn’t changed. Publicly verifiable, but not secret.

Two questions tell them apart

Does it need a key? Can you reverse it?

Tool	Needs a key?	Reversible?
Encoding	No	Yes (trivially)
Hashing	No	No
Encryption	Yes	Yes (with the key)
Signing	Yes	Verifiable, not secret

Use the wrong one and you leak

Encoding as secrecy → Base64 reverses in one step.
Hashing as signing → you can’t tell who sent it.
Encryption to store passwords → a key leak becomes plaintext.
Signing as encryption → signatures don’t hide anything.

A real case: Heartbleed (CVE-2014-0160)

In 2014, OpenSSL’s heartbeat lacked bounds checking, leaking up to 64 KB of process memory per request — potentially including private keys. Everything that relied on that key for secrecy or signing was compromised; encoding and hashing, which need no key, were unaffected. Encryption and signing both hang on the key.

Engineering practice

Base64 only for transport/display — never for secrecy.
SHA-256 / HMAC-SHA256 / SM3 for integrity and password storage (with bcrypt/argon2 + salt).
Only AEAD ciphers for encryption (AES-256-GCM / SM4-GCM).
Ed25519 for signing.

These practices come from building Autional, an open-core identity layer — https://www.autional.com

Reference: RFC 4648 (Base64), FIPS 180-4 (SHA-2), FIPS 197 (AES) / NIST SP 800-38D (GCM), RFC 8032 (Ed25519); Heartbleed (CVE-2014-0160).

How Websites Store Your Password: Hashing Encryption (You Also Need Salt — and Slowness)

Autional — Fri, 09 Oct 2026 04:32:18 +0000

When your password shows up in a breach list, you might tell yourself: “the site encrypted my password, so it should be fine.” The truth is — the site shouldn’t know your password, and doesn’t need to.

From plaintext to slow hashes

Plaintext — the password is stored as-is. RockYou (2009) leaked ~32 million plaintext passwords.
Encryption — lock it in a safe with a key. Problem: the safe can be opened, the key lives on the same machine, and the same password produces the same ciphertext. Adobe (2013, 3DES-ECB) is the textbook case.
Hashing — store only the “shredded” fingerprint; it can’t be reversed. Next login, shred again and compare.
Fast hashes aren’t enough — precomputed dictionaries cover hundreds of millions of common passwords. LinkedIn (2012, unsalted SHA-1) had many passwords recovered within days.
Salting — a unique random salt per user, so the same password yields different hashes. The salt isn’t secret; reusing one salt for everyone is the real danger.
Slow hashing (adaptive) — deliberately slow: bcrypt / scrypt / Argon2, with a tunable cost that rises with hardware.

Three takeaways

Hashing ≠ encryption (can’t reverse vs. can be unlocked);
Always salt;
Make it slow.

Engineering practice

Use a standard slow hash: Argon2id (OWASP-recommended) / bcrypt / scrypt; PBKDF2 with high iterations.
Salt ≥ 32 bits, tune cost upward over time (NIST SP 800-63B).
Never write passwords to logs.

These practices come from building Autional, an open-core identity layer — https://www.autional.com

Reference: OWASP Password Storage Cheat Sheet, NIST SP 800-63B, RFC 9106 (Argon2), RFC 7914 (scrypt); cases: LinkedIn 2012, Adobe 2013, RockYou 2009.

DEV Community: Autional

How JWT Signing Keys Are Issued and Rotated (and Why 'alg' Deserves Distrust)

A JWT is three parts

Keys are a pair

Publishing keys: JWKS + kid

Rotation: overlap or you break everything

Verify with a fixed algorithm — never trust the token

A real case: Storm-0558 (2023)

Engineering practice

Base64 Is Not Encryption: Encoding, Hashing, Encryption and Signing Are Four Different Tools

The four tools

Two questions tell them apart

Use the wrong one and you leak

A real case: Heartbleed (CVE-2014-0160)

Engineering practice

How Websites Store Your Password: Hashing Encryption (You Also Need Salt — and Slowness)

From plaintext to slow hashes

Three takeaways

Engineering practice

Publishing keys: JWKS + `kid`