Wie ich JWT Key Rotation debugge, ohne Verification zu brechen

Wenn JWT Verification genau während eines Signing-Key-Wechsels ausfällt, behandle ich das als Key-Lifecycle-Problem. Token und Verifier können jeweils korrekt sein; der Fehler kann beim Übergang zwischen altem und neuem Key, bei kid oder im JWKS Cache liegen.

Meine Leitfrage lautet:

Kann der Verifier den Key, mit dem dieses Token signiert wurde, während der verbleibenden Token Lifetime noch finden und vertrauen?

Mit Token und Key Set starte ich im JWKS Validator.

1. kid, Issuer und exp zuerst lesen

{
  "alg": "RS256",
  "kid": "signing-key-2026-09"
}

{
  "iss": "https://login.example.com/",
  "exp": 1789203600
}

Ich brauche sofort drei Fakten: Wer sollte den Key besitzen? Welchen kid fordert das Token an? Wie lange kann das Token noch gültig sein?

2. Aktuelles JWKS mit kid vergleichen

Bei geplanter Rotation können Old/New Keys gleichzeitig veröffentlicht werden:

{
  "keys": [
    { "kid": "signing-key-2026-06", "kty": "RSA", "alg": "RS256", "use": "sig" },
    { "kid": "signing-key-2026-09", "kty": "RSA", "alg": "RS256", "use": "sig" }
  ]
}

Fehlt ein alter Key, obwohl alte Tokens noch gültig sind, prüfe ich Removal Timing, falsche Umgebung und falschen Issuer.

3. Planned Rollover gegen Emergency Revocation

Bei einem geplanten Rollover behalte ich den alten Verification Key normalerweise lang genug, damit bereits ausgestellte Tokens auslaufen können.

Nach Key Compromise kann genau das falsch sein. Dann sollen alte Tokens eventuell sofort untrusted werden, auch wenn exp noch in der Zukunft liegt.

Die Ursache der Rotation bestimmt die Overlap Policy.

4. JWKS Caching untersuchen

Ich prüfe:

• Cache TTL;
• Refresh bei unbekanntem kid;
• zusätzliche Gateway/Framework-Caches;
• mehrere Instanzen mit unterschiedlichen Cache-Zuständen;
• CDN/Proxy-Staleness;
• Fehlerpfade, die alte Keys zu lange festhalten.

Ein kid Miss kann einen kontrollierten Refresh vom bereits vertrauten JWKS Endpoint auslösen. Das Token darf die Fetch-Zieladresse nicht frei bestimmen.

5. Neuer Key muss zum selben Trusted Issuer gehören

expected issuer
      ↓
trusted metadata/config
      ↓
trusted JWKS
      ↓
matching kid
      ↓
compatible JWK
      ↓
signature verification

Ein ähnlicher Key aus Staging ist kein erfolgreicher Production-Rollover.

6. Key Metadata prüfen

Auch bei passendem kid kontrolliere ich kty, alg, use und key_ops. Der Algorithmus kommt aus der Application Allowlist, nicht aus untrusted input.

7. Rotation Timing mit Token Lifetime vergleichen

11:59 Token mit altem Key
12:00 neuer Signing Key aktiv
12:01 alter Public Key entfernt
12:30 altes Token noch 29 Minuten gültig

Bei geplanter Rotation ist das eine Verification-Lücke.

Die Overlap-Dauer hängt von Maximum Token Lifetime, Cache-Strategie und Operational Buffer ab.

8. Old und New Token testen

Ich vergleiche ein Token direkt vor und direkt nach Rotation gegen das aktuelle Trusted JWKS. So trenne ich:

• Missing Old Key;
• Missing New Key;
• Stale Cache;
• Wrong Issuer;
• allgemeines Signature Problem.

Bei kid not found nutze ich zusätzlich die JWT-kid-Anleitung.

Verification für einen Rollout nicht abschalten

Wenn ein neuer Key nicht rechtzeitig angekommen ist, repariere ich Publication, Distribution oder Cache. Ich schalte die Signature Verification nicht temporär aus.

So sieht ein gesunder Planned Rollover für mich aus

1. New Public Key im Trusted JWKS veröffentlichen
2. Old Public Key weiter verfügbar halten
3. Neue Tokens mit New Private Key / kid signieren
4. Verifier akzeptieren Old und New Keys
5. Old-Token-Acceptance-Window abwarten
6. Old Key gemäß Policy entfernen

Meine Rotation-Checkliste

1. iss, alg, kid, exp lesen.
2. Expected Issuer bestätigen.
3. Trusted Current JWKS prüfen.
4. Token-kid suchen.
5. kty, alg, use, key_ops prüfen.
6. Mit JWKS Validator verifizieren.
7. Cache Age/Refresh prüfen.
8. Token Lifetime mit Key Availability vergleichen.
9. Planned Rollover vs. Emergency Revocation unterscheiden.
10. Signature Verification während der Reparatur aktiv lassen.

Key Rotation ist für mich Koordination von Token Lifetime, Public-Key-Publishing, Key Selection, Cache Refresh und Issuer Trust — nicht nur das Austauschen eines Private Keys.