# Rotating JWT signing keys without verifier outages > Coordinate JWKS publication, cache refresh, overlapping keys, and emergency retirement on an explicit timeline. Canonical URL: https://www.devobs.io/articles/jwks-key-rotation-without-outages/ By: Lena Fischer Published: 2026-01-26T23:21:57.885Z Updated: 2026-09-05 Section: Architecture A safe signing-key rotation is an overlap protocol, not a key replacement. Publish the new public key before issuing tokens that reference it, keep the old public key available until every token it signed can no longer be accepted, and make verifiers refresh once when they encounter an unknown key identifier. Emergency retirement is a different procedure because overlap may preserve a compromised key. ## Give every key an unambiguous identity A JWT header normally identifies its signing key with `kid`. The issuer's JSON Web Key Set publishes public verification material. [RFC 7517](https://www.rfc-editor.org/rfc/rfc7517) defines JWK and JWK Set structures and the key identifier parameter. Choose unique, opaque identifiers and never reuse a `kid` for different key material. Verifiers must also pin the expected issuer and allowed algorithms; selecting whatever key or algorithm appears in an untrusted token invites confusion. Publish the JWKS at the discovered `jwks_uri`. [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) defines this metadata relationship. Treat discovery and JWKS URLs as issuer configuration, not token-controlled network destinations. Cache the set according to HTTP response policy, apply a bounded maximum staleness suitable for your rotation objective, and preserve a last-known-good set during brief retrieval failures. ## Run normal rotation as a timeline At T0, generate the new private key inside the intended key-management boundary. Publish only its public JWK alongside the current key. Wait at least the longest realistic verifier cache interval plus propagation margin. Observe that verifiers have fetched the set; do not infer readiness from the issuer's own endpoint. At T1, begin signing new tokens with the new key and its new `kid`. Keep serving the old public key. Verifiers that still have an older cache will see the unknown `kid`; they should perform one rate-limited refresh and retry verification once. Coalesce simultaneous refreshes so a traffic spike does not turn key rotation into a thundering herd. If the refreshed set still lacks the key, reject the token. At T2, after the maximum lifetime of old tokens plus clock-skew and queueing allowances, remove the old public key. Include every token type in this calculation: access tokens, ID tokens, logout tokens, and delayed jobs may have different lifetimes. If verifiers allow offline tokens beyond that bound, the issuer cannot safely know when removal is harmless. ## Design failure and rollback first Track signing counts by `kid`, verification counts by `kid`, unknown-key refreshes, JWKS fetch failures, and token rejections. A canary verifier should fetch through the same CDN and network path as production. Before T1, test a token signed by the new key against representative verifier versions. Rollback during normal rotation means signing with the old private key again while both public keys remain published. Keep that private key available until the new key is proven, but control access tightly. Never roll back by reassigning the new material to the old `kid`. Emergency rotation starts by deciding whether the suspected private key can still be trusted. If not, stop signing with it, publish and use a new key immediately, and remove the compromised public key as soon as the incident policy demands. That will invalidate otherwise unexpired tokens. Coordinate user-facing reauthentication and downstream cache purges; availability is subordinate to containment. Ory Hydra provides OAuth 2.0 and OpenID Connect, so the same issuer/verifier contract applies when it issues JWTs in a chosen deployment. Ory Network and self-hosted Hydra should be assessed separately for operational key-control procedures; do not transfer self-hosting steps to the managed service. Create a rotation worksheet with publish, activate, retire, and rollback timestamps. Inventory the longest token lifetime and longest verifier cache today. If either is unknown, measure it before the next key change; those two values define the minimum safe overlap. ## Source references - -