How do you rotate a JWT signing key using kid and a JWKS without rejecting live tokens?

## Why rotation needs an overlap At any moment there are tokens in flight signed with the current key and verifiers holding a cached copy of the key set that may be minutes or hours old. A rotation that changes the signing key and the published set at the same instant breaks both groups: verifiers with a stale cache have not seen the new key, and tokens already issued reference a key you just deleted. The fix is to make the two populations overlap in time, which is exactly what the `kid` header parameter exists to support — it lets more than one key be valid simultaneously and lets each token say which one it used. ## The four-step procedure **1. Publish before you use.** Generate the new key pair, ideally inside a KMS or HSM so the private half is never exported. Add the public key to the JWKS with a fresh, distinct `kid`. Do not reuse an identifier; a `kid` that changes meaning is worse than no `kid` at all. The issuer keeps signing with the old key throughout this step. Nothing in the system changes behaviour yet. **2. Wait out the caches.** Every verifier caches the key set for some period. The safe wait is the maximum of those cache lifetimes plus a margin for deploys, cold starts, and any CDN in front of the endpoint. Publishing the key set with explicit, modest cache directives makes this window a number you control rather than a guess. Skipping this step is the single most common way rotations cause an outage. **3. Switch signing.** Point the issuer at the new key. Every new token now carries the new `kid`, and verifiers already hold that key, so they resolve it from cache with no network call. Old tokens still verify because the old key is still published. This is the moment to watch verification-error rates: a spike here means some verifier never picked up the new key, and rolling back is cheap because the old key is still active. **4. Retire the old key.** A token signed just before the switch remains valid for its whole lifetime. So the old public key must stay in the JWKS for at least the maximum access-token lifetime plus the clock-skew tolerance verifiers allow. After that, remove it from the published set and destroy or disable the private half. Removing it earlier produces exactly the failure rotation was supposed to avoid. ## What verifiers must do to make it work The issuer's procedure only works against well-behaved verifiers: - **Select by `kid`.** Trying every key in the set until one verifies appears to work and quietly removes the ability to reason about which key signed what. - **Refresh on an unknown `kid`, with a rate limit.** This is what lets an emergency rotation propagate faster than the cache TTL. Without a limit, tokens carrying random identifiers turn into an outbound request flood at the issuer. - **Cache negative results briefly**, so a burst of unknown identifiers does not retry per request. - **Serve from the last good copy on fetch failure.** Public keys change rarely; availability of the issuer's endpoint should not gate every API request. - **Bind algorithm to key.** After resolving a `kid`, confirm the key type matches the algorithm the verifier is configured to accept. ## Routine rotation versus emergency revocation These are different operations and conflating them is a common weak answer. **Routine rotation** is scheduled, overlapped, and invisible: no token is ever invalidated. Its cadence is a policy choice — commonly months — and the point is to exercise the procedure so it is boring and to bound how long any one key is exposed. **Emergency revocation** happens when a private key may have leaked. Then the overlap is the problem: you remove the compromised key from the JWKS immediately, force verifiers to refresh, and accept that every token signed with it stops validating. Users re-authenticate. Because that is disruptive, short token lifetimes are what make the emergency path survivable — with a fifteen-minute access token, the damage window and the recovery window are both small. ## The signal an interviewer is listening for A weak answer says "change the key and update the JWKS". A strong one names the two clocks that govern the procedure — the verifier cache lifetime, which sets how long you wait *before* switching, and the token lifetime, which sets how long you wait *after* — and can say what breaks if either is ignored.