JWT-Expiration und Clock Skew
Wie exp, nbf, iat, Toleranzfenster, Retries und regionale Uhren echte Validierungsentscheidungen beeinflussen.
JWT-Expiration-Bugs entstehen selten daraus, dass jemand exp nicht versteht. Die meisten wissen, dass es ein Unix-Timestamp ist und abgelaufene Tokens fehlschlagen müssen. Probleme beginnen an den Rändern: Retry-Queues, Mobilgeräte mit falschen Uhren, CDN-Worker in verschiedenen Regionen und Services mit unterschiedlicher Clock-Skew-Toleranz. Fünf Minuten Toleranz können hilfreiche Zuverlässigkeit sein oder jedes gestohlene Token still verlängern.
Die Claims sind simpel, das System nicht
exp sagt, wann ein Token ungültig wird. nbf sagt, wann es gültig wird. iat sagt, wann es ausgestellt wurde, wird aber ohne zusätzliche Policy oft nur informativ behandelt. In einem einzelnen Prozess mit funktionierendem NTP klingt das leicht. In einem verteilten Stack kann ein Token in einer Region erzeugt, in einer anderen geprüft, nach Timeout erneut gesendet und Sekunden später an eine Worker-Queue übergeben werden.
Angreifer interessieren sich für das Toleranzfenster. Wenn Access Tokens offiziell zehn Minuten leben und der Verifier fünf Minuten Skew akzeptiert, liegt die nutzbare Lebensdauer nach Diebstahl eher bei fünfzehn Minuten. Wenn Refresh-Endpunkte andere Toleranzen nutzen als APIs, kann ein gestohlenes Token an einer Stelle scheitern und sich an anderer Stelle noch erneuern.
Ein Skew-Fenster wählen
Nutze die kleinste Toleranz, die zum gemessenen Uhrverhalten passt, nicht irgendeinen Standardwert aus Folklore. Dreißig bis sechzig Sekunden reichen für viele serverseitige Systeme mit gesunder Zeitsynchronisierung. Mobile und Desktop-Clients können minutenweit falsch liegen, aber der Server sollte Autorität bleiben. Ist die Client-Uhr schlecht, verbessere Refresh- und Retry-UX, statt jedem Token großzügig Gnadenzeit zu geben.
Randfälle zum Testen
Teste Tokens, die seit einer Sekunde abgelaufen sind, knapp innerhalb des Fensters und knapp außerhalb. Teste nbf in naher Zukunft. Teste iat weit in der Zukunft, weil manche Systeme versehentlich Tokens von morgen akzeptieren. Prüfe auch Hintergrundjobs. Wenn eine Request Arbeit mit einem Token einreiht, das vor Ausführung abläuft, sollte der Worker eine abgeleitete Autorisierungsentscheidung oder Service-Credentials nutzen, nicht einem alten User-Token neu vertrauen.
Logging und Incident Response
Logge Verifier-Uhrzeit, Claim-Timestamp, angewendeten Skew und Fehlergrund. Ohne diese Felder werden Expiration-Incidents zum Rätselraten. Rohe Tokens gehören nie ins Log. Bei vermutetem Token-Diebstahl kann weniger Skew eine sinnvolle Eindämmung sein, aber nur wenn klar ist, welche Services ihn konsistent erzwingen.
Eine vernünftige Policy
Kurzlebige Access Tokens, enge Toleranz, explizites Refresh-Verhalten und einheitlicher Verifier-Code schlagen clevere Ausnahmen. Dokumentiere die genaue Interpretation von exp, nbf und iat pro Issuer. Die Policy sollte so langweilig sein, dass ein On-Call mit drei Timestamps und einem Servicenamen das Ergebnis vorhersagen kann.