JWT-Ablauf prüfen
Der exp-Claim ist ein Unix-Zeitstempel und sagt auf den ersten Blick nichts. Fügen Sie das Token ein, und diese Seite macht daraus ein Datum, eine vertraute Zeitzone und einen klaren Satz.
Signieren Sie ein eigenes Token, um einen Endpunkt zu testen. Alles wird auf dieser Seite berechnet.
Schlüssel und fertiges Token bleiben in Ihrem Browser: Beides wird nirgendwohin gesendet und steht auch in keinem geteilten Link.
Prüfen Sie dieses Token in Ihrem eigenen Code. Das Snippet richtet sich nach dem Algorithmus im Header.
Prüfen, wann ein JSON Web Token abläuft
Eine abgelehnte Anfrage bleibt selten lange rätselhaft: Zuerst lohnt die Frage, ob das Token bei der Ankunft überhaupt noch lebte. Nur steht die Antwort als etwas wie 1790208000 im Token, und das liest niemand auf einen Blick. Fügen Sie das Token ein, und die Zeile über dem dekodierten Header sagt es in Worten – vor zwei Tagen abgelaufen, läuft in achtundfünfzig Minuten ab, noch nicht gültig –, während die Claim-Tabelle das volle Datum in Ihrer Zone zeigt.
Alles wird auf der Seite dekodiert. Das zählt hier besonders, denn ein Token ist ein aktiver Zugang: Wer ein gültiges besitzt, kann meist als dessen Subjekt handeln – bis genau zu dem Moment, von dem diese Seite spricht. Nichts, was Sie einfügen, wird hochgeladen, protokolliert oder behalten.
Die drei Claims, die Zeit tragen
| Claim | Bedeutung | Wie ein falscher Wert aussieht |
|---|---|---|
exp | Ab diesem Moment wird das Token nicht mehr angenommen | Ein 401, der nach jeder Anmeldung nach derselben Zeitspanne auftaucht |
nbf | Vor diesem Moment darf es nicht benutzt werden | Ein frisches Token, das in den ersten Sekunden abgelehnt wird |
iat | Wann es ausgestellt wurde | Wird für Höchstalter-Regeln genutzt: ein altes, aber nicht abgelaufenes Token scheitert trotzdem |
Alle drei zählen Sekunden seit der Unix-Epoche, nicht Millisekunden – ein von Hand mit einem JavaScript-Date.now() geschriebenes JWT landet im Jahr 58.000 und wird von niemandem akzeptiert. Wenn Sie eine dieser Zahlen einzeln umrechnen wollen, macht der Timestamp-Konverter dieselbe Rechnung in beide Richtungen.
Abgelaufen oder nur aus dem Takt?
Zwei Maschinen sind sich über die Uhrzeit selten auf die Sekunde einig, deshalb lässt jeder vernünftige Prüfer etwas Spielraum – dreißig bis sechzig Sekunden sind üblich. Diese Toleranz ist der Grund, warum ein Token hier um ein paar Sekunden abgelaufen aussehen und trotzdem angenommen werden kann, und warum ein Token von einem Server mit vorgehender Uhr in seinen ersten Augenblicken als noch nicht gültig abgelehnt wird. Scheitert ein Token weit außerhalb dieses Fensters, liegt es nicht an der Uhr.
Die andere Hälfte der Antwort ist die Signatur. Ein abgelaufenes Token kann eine einwandfreie Signatur tragen, und ein gefälschtes kann ein exp weit in der Zukunft nennen; die beiden Fragen sind voneinander unabhängig. Diese Seite beantwortet beide – prüfen Sie die Signatur mit dem Schlüssel unter dem Token, und ein abgelaufenes Ergebnis wird auch dann noch als solches genannt, wenn die Signatur gültig ist.
Wie lange ein Token leben sollte
Kurz, denn ein Token lässt sich nicht zurückholen. Einmal signiert, ist jeder, der es hat, dieser Benutzer, bis exp vorbei ist; ein Access-Token mit fünfzehn Minuten Lebensdauer begrenzt den Schaden eines Lecks also auf eine Weise, wie es eines mit dreißig Tagen nie könnte. Üblich ist die Kombination aus kurzem Access-Token und langem Refresh-Token, das serverseitig liegt und widerrufen werden kann – genau dieser Tausch steht im Vergleich mit Session-Cookies.
Wenn Sie dieses Verhalten testen statt diagnostizieren wollen, signiert der JWT-Generator ein Token, das in fünf Minuten abläuft – oder eines ganz ohne Ablauf –, damit Sie sehen, wie Ihr eigener Code reagiert.