Why Rotate Keys?
Even without a confirmed breach, cryptographic best practice requires periodic key rotation. Keys should be rotated:
- On a regular schedule (e.g., every 90 days).
- Immediately upon suspected compromise.
- When migrating to a stronger algorithm (e.g., RS256 → ES256).
The Old Way Was Painful
In the shared-secret (HS256) world, rotating the secret means updating it on every service simultaneously. Miss one service and it starts rejecting all tokens. Do it sequentially and you have a window where some services accept old tokens and some accept new ones. Either way, you're coordinating a distributed system change under time pressure.
The JWKS Rotation Playbook
JWKS makes rotation a non-event:
Step 1 — Generate: The Auth Server generates a new RSA or EC key pair. The new key gets a fresh kid (e.g., key-id-456).
Step 2 — Publish: The new public key is added to the JWKS endpoint. The endpoint now lists both key-id-123 (old) and key-id-456 (new).
Step 3 — Switch Signing: The Auth Server begins signing all new tokens with the new private key (key-id-456). Old tokens already in circulation still carry kid: key-id-123.
Step 4 — Grace Period: Both keys remain in the JWKS. Verifiers can validate both old tokens (using key-id-123) and new tokens (using key-id-456) without any configuration change.
Step 5 — Retire: Once the maximum token lifetime has passed (e.g., 24 hours after the last token signed with key-id-123 expires), remove key-id-123 from the JWKS.
Timeline:
T+0h New key generated, added to JWKS. Auth server switches signing.
T+0h → T+24h Both keys in JWKS. Old tokens still valid.
T+24h Old key removed from JWKS. Rotation complete.
Services verifying tokens never need a restart, config change, or deployment. They automatically use whichever public key matches the kid in the incoming token.
A common interview question is: "How do you rotate JWT signing keys without causing downtime?" The answer has three parts: (1) use asymmetric keys with JWKS so verifiers don't need the private key; (2) publish the new public key before switching signing, so verifiers can cache it; (3) keep the old public key in the JWKS for at least one full token TTL as a grace period. Candidates who only say "update the secret" are revealing HS256 thinking.