Ein JSON Web Token besteht aus drei Base64url-Blöcken, durch Punkte verbunden: Header, Payload und Signatur. Dieses Tool trennt sie und zeigt dir, was drinsteht. Es prüft die Signatur nicht, und das ist Absicht — der Grund ist zwei Minuten deiner Zeit wert.
Dekodieren ist nicht Verifizieren
Das sind völlig verschiedene Vorgänge, und sie zu verwechseln verursacht Sicherheitsvorfälle. Dekodieren braucht nichts: Header und Payload sind Base64url-kodiert, nicht verschlüsselt — wer das Token hat, liest jeden Claim darin. Verifizieren braucht den Signaturschlüssel und beantwortet eine andere Frage: Wurde dieses Token wirklich von dem ausgestellt, der behauptet es zu sein, und hat es seither jemand verändert?
Ein Werkzeug, das ein Token liest, beweist nichts über dessen Gültigkeit. Fügst du hier ein abgelaufenes Token ein, siehst du seinen Inhalt trotzdem sauber dargestellt. Dass die Dekodierung klappt, sagt dir nur, dass die Zeichenkette wohlgeformt ist — mehr nicht.
Warum dieses Tool Signaturen nicht prüft
Viele JWT-Webseiten bieten neben dem Token ein Feld für dein Signaturgeheimnis. Überleg, was da von dir verlangt wird. Bei HS256 ist das Geheimnis derselbe Schlüssel, der gültige Tokens prägt — gib ihn einer Webseite, und wer diese Seite betreibt, kann für dein System beliebige Tokens fälschen. Es gibt keinen Weg, eine symmetrische Signatur zu prüfen, ohne zugleich die Fähigkeit zum Signieren abzugeben.
Dieses Tool fragt also nicht danach, und du solltest jedem misstrauen, der es tut. Prüfe Signaturen in deinem eigenen Code, in deiner eigenen Laufzeitumgebung, mit dem Schlüssel aus deinem eigenen Secret Store. Ein Signaturschlüssel gehört an genau zwei Orte: den Dienst, der Tokens ausstellt, und den, der sie prüft.
Die Claims, über die man stolpert
Die Zeitstempel sind die üblichen Verdächtigen. RFC 7519 definiert exp, iat und nbf als NumericDate — Sekunden seit der Unix-Epoche. JavaScripts Date.now() liefert Millisekunden. Das eine dort zu übergeben, wo das andere erwartet wird, ist der häufigste JWT-Fehler überhaupt: ein Token, das 1970 abläuft, oder eines, das die nächsten fünfzigtausend Jahre gültig bleibt. Zeigt ein dekodiertes exp ein Datum in ferner Vergangenheit oder absurder Zukunft, hast du einen Faktor 1000 gefunden.
Die andere häufige Überraschung ist nbf, "not before". Ein Token kann einwandfrei signiert und unabgelaufen sein und trotzdem abgelehnt werden, weil es noch nicht gültig ist — meist ein Symptom auseinanderlaufender Uhren zwischen ausstellender und prüfender Maschine, nicht ein Problem des Tokens.
Das alg-Feld ist eine Anweisung, keine Beschreibung
Der Header trägt einen "alg"-Claim, der den Signaturalgorithmus benennt, und die klassische JWT-Schwachstelle ist eine Bibliothek, die ihm vertraut. Liest ein Validator alg aus dem Token und prüft entsprechend, kann ein Angreifer alg auf "none" setzen, die Signatur entfernen und hereinspazieren — das Token selbst hat dem Validator gesagt, er solle nicht prüfen.
Der verwandte Angriff tauscht RS256 gegen HS256. Bei RS256 wird das Token mit einem privaten Schlüssel signiert und mit dem öffentlichen geprüft. Ein naiver Validator, der alg als HS256 liest, verwendet diesen öffentlichen Schlüssel als HMAC-Geheimnis — und der öffentliche Schlüssel ist per Definition öffentlich. Beide Angriffe sind alt, und gepflegte Bibliotheken lehnen heute alg-Werte ab, die der Aufrufer nicht ausdrücklich erlaubt hat. Siehst du ein Token, dessen Header "none" sagt, testest du entweder etwas oder schaust auf einen Angriff.
Was nicht in einen Payload gehört
Da der Payload für jeden lesbar ist, der das Token hat, ist er kein Ort für Privates. Keine internen Notizen zum Benutzer, keine Berechtigungslogik, die du lieber nicht erklären würdest, keine personenbezogenen Daten über das hinaus, was das Token für seine Aufgabe braucht. Die Signatur verhindert Veränderung, nicht Lesen — eine Unterscheidung, die schon viele Teams blamiert hat, die ein signiertes Token für ein versiegeltes hielten.
Häufige Fragen
Wird mein Token an einen Server geschickt?
Nein. Dieses Tool ist als "client" gekennzeichnet: Aufteilen und Dekodieren passieren in deinem Browser-Tab, das Token verlässt das Gerät nie. Trotzdem lohnt es, die Gewohnheit grundsätzlich zu hinterfragen — ein JWT ist ein aktives Zugangsmittel. Hast du ein Produktions-Token in irgendeine Webseite eingefügt, diese eingeschlossen, ist die sicherste Annahme, dass es rotiert werden sollte.
Kann ich prüfen, ob dieses Token gültig ist?
Nicht hier, und auf keiner Seite, die du nicht selbst betreibst — siehe oben. Mit bloßem Auge prüfen kannst du, ob das Token abgelaufen ist, denn exp steht direkt im dekodierten Payload. Das deckt den häufigsten Grund ab, warum ein Token nicht mehr funktioniert, ohne dass ein Schlüssel den Besitzer wechselt.
Warum wird als Ablauf ein Datum im Jahr 1970 angezeigt?
Weil ein Millisekunden-Zeitstempel als Sekunden gelesen wird. Teile durch 1000 und das Datum sieht vernünftig aus. Was auch immer das Token erzeugt hat, verwendet Date.now(), wo RFC 7519 Math.floor(Date.now() / 1000) erwartet.
Kann ich ein Token hier bearbeiten und neu signieren?
Nein. Ein einziges geändertes Zeichen im Payload macht die Signatur ungültig, und eine neue gültige zu erzeugen braucht den Signaturschlüssel — der, wie oben beschrieben, nichts ist, was man in eine Webseite einfügt. Tokens bearbeitet man in der eigenen Testsuite mit einem Testschlüssel.
Das Token hat Punkte, lässt sich aber nicht dekodieren. Warum?
Meist ist es kein JWT. Verschlüsselte Tokens (JWE) haben fünf statt drei Segmente, und ihr Payload ist ohne Schlüssel tatsächlich unlesbar. Die andere häufige Ursache ist Abschneiden: Tokens sind lang und werden von Log-Formatierern, Terminalbreiten und Tabellenzellen gekappt. Endet das mittlere Segment abrupt, fehlen dir wahrscheinlich Zeichen, statt dass das Token fehlerhaft wäre.