JWKS-Cache und Rotationsfehler
Die unsauberen Randfälle hinter JWKS-Caching, Schlüsselrotation, veralteten kid-Werten und robustem Verifier-Design.
JWKS wirkt im Diagramm einfach: Der Issuer veröffentlicht Schlüssel, Services cachen sie, Tokens werden geprüft. Die Fehler entstehen im Timing. Ein Schlüssel rotiert, während ein Cache veraltet ist. Ein neues kid erscheint, bevor jede Region das JWKS-Update hat. Ein Verifier aktualisiert bei jedem Miss und gibt Angreifern damit einen kleinen Denial-of-Service-Hebel. Dafür muss kein Signaturalgorithmus gebrochen sein. Verteilte Systeme verhalten sich einfach wie verteilte Systeme.
Zwei schlechte Cache-Strategien
Die erste schlechte Strategie ist Caching für immer. Normale Rotation wird dadurch unangenehm, also vermeiden Teams sie bis zum Vorfall. Die zweite schlechte Strategie ist ein JWKS-Fetch pro Request oder pro unbekanntem kid. Das hält Schlüssel frisch, macht den Issuer aber zum Teil des Hot Paths. Ein Angreifer kann tausende Tokens mit zufälligen kid-Werten senden und ohne Miss-Rate-Limit eine Welle ausgehender Fetches auslösen.
Ein besseres Design nutzt eine normale TTL, bedient während kurzer Issuer-Probleme aus dem Cache und aktualisiert im Hintergrund, wenn ein neues kid auftaucht. Ein unbekanntes kid sollte höchstens einen Refresh pro Issuer in einem kurzen Fenster auslösen. Andere Requests sollten mit dem aktuellen Cache geschlossen fehlschlagen, nicht hinter einem Remote-Fetch warten.
Die Reihenfolge der Rotation zählt
Veröffentliche den neuen Public Key, bevor Tokens mit dem neuen Private Key signiert werden. Behalte den alten Public Key, bis die längste Token-Lebensdauer plus Clock Skew abgelaufen ist. Wenn Access Tokens fünfzehn Minuten leben und Clients fünf Minuten abweichen können, erzeugt das Entfernen nach zehn Minuten sichere Fehlablehnungen. Die Zeitlinie muss CDN-Propagation, regionalen Rollout und mobile Clients mit Offline-Tokens enthalten.
Sinnvolle Signale
Erfasse Verifikationsfehler nach Issuer, kid, Algorithmus und Grund. Ein Spike bei unknown kid nach einem Deploy bedeutet etwas anderes als ein Spike bei bad signature. Logge Cache-Alter und Refresh-Ergebnis. Im Incident zeigen diese Felder, ob es um einen kompromittierten Schlüssel, einen schlechten Rollout oder einen kaputten Netzwerkpfad zum JWKS-Endpunkt geht.
Fehlermodi testen
Ein Pentest sollte veraltetes JWKS-Verhalten prüfen, nicht nur gefälschte Tokens. Kann die App während der Rotation alte Tokens weiter verifizieren? Akzeptiert sie ein Token, das mit einem entfernten Schlüssel signiert wurde? Was passiert, wenn der JWKS-Endpunkt 500 liefert oder langsam antwortet? Verteidiger sollten Rotation mit einem Staging-Issuer und erzwungenen Cache-Zuständen üben. Wenn die erste echte Rotation unter Druck stattfindet, ist das Runbook zu spät.