{
  "id": 3936854,
  "title": "How to Rotate JWT Signing Keys Without Breaking Every Active Session",
  "url": "https://urgent.news/2026/08/28/how-to-rotate-jwt-signing-keys-without-breaking-every-active-session",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-28T09:54:11.000Z",
  "source": {
    "name": "HackerNoon",
    "slug": "hackernoon",
    "url": "https://hackernoon.com/how-to-rotate-jwt-signing-keys-without-breaking-every-active-session?source=rss"
  },
  "original_language": "en",
  "account": "When rotating a JWT signing key naively, you simply swap out the old key with a new one and redeploy. However, this approach causes every token issued under the old key to stop verifying immediately, resulting in all logged-in users being kicked out at once. This common issue is often overlooked in JWT tutorials because it only becomes a problem after the initial implementation is working.\n\nScheduled key rotation is essential for maintaining security hygiene, similar to periodically updating database credentials or API keys, limiting the duration of usefulness for any compromised key. Emergency rotation is another scenario, necessitating swift action if a key is leaked, making it a more urgent version of the same problem.\n\nThe key to successful rotation lies in adding a new key rather than replacing the old one. This works because a JWT header includes a kid (key ID) claim, identifying which key signed it. Your verification code reads the kid, looks up the corresponding key, and verifies against the matching one. This lookup is facilitated by a JWKS (JSON Web Key Set) endpoint. As long as both old and new public keys are included in the JWKS response during the transition, tokens signed under either key will still verify correctly, eliminating the need for a mass logout.\n\nTo execute this rotation sequence, generate a new key pair with a new key ID and private key kept secret. The new public key is then added to the JWKS response, alongside the old one. The old key should not be removed yet, as this is a step often skipped, leading to user logouts. Existing tokens, signed with the old key, continue to verify fine since the old public key remains published. As existing tokens naturally expire, signing new tokens with the new private key ensures a smooth transition.\n\nThe rotation is considered complete only after the old public key is removed from the JWKS once confidence is established that no references to it exist. This marks the actual completion of the rotation process.\n\nImplementing this rotation method is more challenging with HS256 (HMAC using a secret key) compared to RS256 (RSA using a public/private key pair). With HS256, the same secret key is used for signing and verifying, requiring coordination of a secret change across all verifying services simultaneously without the fallback provided by JWKS-style transitions. When choosing between HS256 and RS256 for systems where key rotation is a concern, the practical implications of this difference should be carefully considered.",
  "summary": "Rotating a JWT signing key the naive way logs out every user at once. Here's the kid-based rotation pattern that avoids it entirely.",
  "key_points": [
    "Naive key rotation kicks out all active sessions",
    "Add new key, keep old one, use kid claim in JWT header",
    "Remove old public key after confirming no references remain"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}