Dekodieren Sie die Claims lokal mit dem JWT-Decoder.
Warum Tokens überhaupt ablaufen
Kurzlebige Zugriffstokens begrenzen den Schaden eines Lecks: Ein Angreifer hat Minuten, nicht Monate. Der exp-Claim speichert den Ablauf als absoluten Unix-Zeitstempel in Sekunden.
Die meisten Auth-Bibliotheken prüfen exp automatisch. Wenn ein Token abgelehnt wird, das Sie für gültig hielten, liegt es meist an drei Dingen: echtem Ablauf, Einheitenfehlern oder Clock Skew.
Die Claims, die die Lebensdauer steuern
Alle drei Werte sind NumericDate: Sekunden seit der Unix-Epoche (1970-01-01T00:00:00Z). In UTC umgerechnet wird aus einem Wert wie 1784563200 ein klares Datum mit Uhrzeit – meist der Moment, in dem der Fehler offensichtlich wird. Prüfen Sie jeden Claim einzeln.
| Claim | Bedeutung | Häufiger Fehler |
|---|---|---|
| exp | Ablaufzeit (Unix-Sekunden) | Vergleich mit Millisekunden statt Sekunden |
| iat | Ausgabezeit (Unix-Sekunden) | Ein weit in der Zukunft liegendes iat deutet auf Skew oder Fälschung |
| nbf | Nicht gültig vor (Unix-Sekunden) | Token wird bis dahin abgelehnt; auf Zukunfts-Werte achten |
| iss / aud / sub | Aussteller, Zielgruppe, Subjekt | Fehlkonfiguration sieht aus wie ein Ablauf-Bug |
Was Clock Skew tatsächlich bewirkt
Clock Skew ist die Differenz zwischen der Uhr des Ausstellers und der des Prüfers. NTP hält Server meist nahe beieinander, aber Container, CI-Runner und Cloud-Funktionen können driften oder mit eingefrorener Uhr starten.
Liegt der Prüfer hinter dem Aussteller, wirkt ein frisches Token noch nicht gültig. Liegt er vorn, wirkt ein gültiges Token abgelaufen. Beides erzeugt verwirrende Fehler wie „token used before issued“ oder „token expired“.
Verifikations-Bibliotheken überbrücken die Differenz mit einer Toleranz (leeway), einem kleinen Toleranzfenster um die Claims. Mit 30 Sekunden Toleranz passiert ein exp bis zu 30 Sekunden in der Vergangenheit weiterhin, auch ein nbf bis zu 30 Sekunden in der Zukunft wird akzeptiert. Das fängt normale NTP-Drift ab, ohne das Token zu verändern.
Ablauf-Fehler lokal debuggen
- Kopieren Sie das Token und öffnen Sie den JWT-Decoder.
- Lesen Sie exp, iat und nbf aus dem Payload.
- Wandeln Sie sie mit dem Zeitstempel-Konverter in lesbare Zeiten um.
- Vergleichen Sie jeden Wert mit der aktuellen UTC-Zeit des Servers.
- Prüfen Sie die Server-Uhr mit dem date-Befehl gegen eine NTP-Quelle.
- Setzen Sie eine kleine Toleranz (30–60 Sekunden) und testen Sie erneut.
Warnung: Beheben Sie Skew nicht mit stundenlanger Toleranz. Große Toleranz verlängert die Token-Lebensdauer still und schwächt genau die Sicherheit, die exp bieten soll.
Präventions-Checkliste
- Serveruhren per NTP synchron halten, auch CI-Runner und Container
- Mit einer Toleranz von 30–60 Sekunden prüfen, nie mehr
- exp/iat/nbf immer in Unix-Sekunden vergleichen, nie Millisekunden
- In Testumgebungen langlebigere Tokens ausstellen statt die Toleranz in Produktion zu erhöhen
- Nicht bei jeder Anfrage ein neues Token ausstellen; das aktuelle bis exp wiederverwenden, außer es gibt einen echten Rotationsgrund
FAQ
Q.Warum läuft ein Token vor seiner angegebenen Lebensdauer ab?
A.Meist weil die Uhr des Prüfers vor der des Ausstellers liegt (Clock Skew) oder exp mit der falschen Einheit berechnet wurde. Dekodieren Sie das Token und vergleichen Sie den Claim mit der aktuellen UTC-Zeit. Liegt exp bei einem frischen Token nur ein oder zwei Minuten in der Vergangenheit, ist das Skew; weicht der Wert um den Faktor 1000 ab, sind es Millisekunden.
Q.Welche Toleranz sollte ich verwenden?
A.30–60 Sekunden sind üblich: genug für NTP-Drift, klein genug, um den Ablauf aussagekräftig zu halten. Für CI-Komfort lieber langlebigere Tokens ausstellen als die Prüfung zu lockern. Eine gelockerte Prüfung gilt überall, nicht nur in CI.
Q.Sollte ich Sekunden oder Millisekunden für JWT-Zeitclaims verwenden?
A.Sekunden. RFC 7519 definiert NumericDate als Sekunden seit der Unix-Epoche. Millisekunden in exp-Vergleichen sind eine der häufigsten Ursachen für scheinbare Ablauf-Bugs. Ein schnelles Indiz: ein frisches Token, dessen exp in den 2030er-Jahren liegt oder dessen Lebensdauer Jahrhunderte ergibt.
Q.Warum meldet meine Bibliothek „token used before issued“?
A.Dieser Fehler stammt vom iat- oder nbf-Claim: Der Prüfer geht davon aus, dass das Token in der Zukunft ausgestellt wurde. Meist liegt seine Uhr hinter der des Ausstellers, oder die Aussteller-Uhr ging beim Erzeugen vor. Eine kleine Toleranz fängt das ab; bei Minuten braucht eine Uhr einen NTP-Abgleich.
Referenzen
- RFC 7519 – JSON Web Token (JWT): https://www.rfc-editor.org/rfc/rfc7519
- RFC 7515 – JSON Web Signature (JWS): https://www.rfc-editor.org/rfc/rfc7515
- OWASP JSON Web Token Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html
Token jetzt dekodieren
Header und Payload im Browser, read-only. exp, iat und nbf in Sekunden prüfen.
Claims lesen, bevor Sie Code ändern
Dekodieren Sie das Token, rechnen Sie exp, iat und nbf mit dem Zeitstempel-Konverter um und vergleichen Sie in UTC mit der Server-Uhr. Die meisten „abgelaufen“-Fehler sind Skew oder Einheitenfehler.
Sind die Uhren synchron und rechnet die Mathematik, fängt eine Toleranz von 30-60 Sekunden NTP-Drift ab, ohne den Ablauf auszuhebeln. Dekodieren Sie Tokens mit dem JWT-Decoder.