Key Rotation with kid
kid rotation is the practice of introducing a new signing key under a new Key ID while verifiers temporarily accept both the old and new kids during an overlap window. Issuers begin signing with the new kid after publishing its public material in JWKS or distributing a new HMAC secret mapped to that kid. After the maximum access-token lifetime passes, the old kid is removed from verifiers and from JWKS. This pattern enables zero-downtime rotation for both symmetric and asymmetric JWT deployments. Without kid, verifiers must guess which secret to try or force a hard cutover that invalidates all sessions immediately. Emergency rotations after compromise may shorten the overlap window intentionally to reduce attacker usefulness of stolen keys.
Why It Matters
Standing rotation capability is a hallmark of mature authentication platforms. Teams that skip kid discover during incidents that they cannot rotate without a painful global logout. Implement kid early, rehearse rotations in staging with production-like TTLs, and monitor verification failures by kid during cutovers so you can detect mispublished keys quickly. Ship dual-verify windows by default: publish the new kid, issue with the new key, then retire the old kid after the longest access-token TTL plus a safety buffer. Alert on sudden unknown-kid rates during every rotation.
Related Terms
Related Comparisons
Related Tools
Related Articles
Frequently Asked Questions
How long should dual-verify last?
At least the maximum access-token lifetime plus a safety buffer for clock skew and retries. Some teams keep the previous kid until refresh-token cycles also settle.
Does kid encrypt or hide the key?
No. kid is a public identifier for key selection. Confidentiality comes from protecting private keys and secrets, not from obscuring kid strings.
Can I rotate HS256 without JWKS?
Yes by distributing secrets out-of-band, but every verifier still needs a kid-to-secret map that you update in a controlled order with a dual-verify window.