JWT-Parser

Über dieses Tool

Der JWT-Parser macht ein JSON Web Token lesbar: Header und Payload erscheinen als formatiertes JSON, Zeitangaben wie exp, nbf und iat als Datum. Außerdem zeigt er, ob das Token nach seinen Zeitangaben gerade gültig, abgelaufen oder noch nicht gültig ist. Optional lässt sich eine HS256-, HS384- oder HS512-Signatur mit dem eigenen Geheimnis prüfen. Token und Geheimnis bleiben im Browser-Tab, werden nicht gesendet, nicht gespeichert und nie in den Link übernommen.

Wofür du es nutzen kannst

Inhalt eines Tokens aus einem Request, Log oder Browser-Speicher ansehen
Prüfen, ob ein Token abgelaufen ist und wann es abläuft
Herausfinden, wer ein Token ausgestellt hat (iss), für wen es gilt (sub) und für welchen Empfänger es bestimmt ist (aud)
Bei Login-Fehlern kontrollieren, ob exp, nbf oder iat plausibel sind, etwa nach Abweichungen zwischen Uhren
Erkennen, ob Zeitwerte versehentlich in Millisekunden statt Sekunden geschrieben wurden
Eine HS-Signatur mit dem eigenen Secret testen, etwa beim Debuggen einer Anmeldung
Einen Test-Token auf das unsichere Verfahren „alg: none“ prüfen
Mit dem Warntest feststellen, ob ein Token mit einem gängigen Standardgeheimnis wie „secret“ signiert ist
Header und Payload als JSON kopieren, um sie in Tickets oder Testfällen zu verwenden

Häufige Fragen

Wie lese ich den Inhalt eines JWT?

Füge das Token in das Eingabefeld ein. Es wird sofort dekodiert, Header und Payload erscheinen als JSON. Ein vorangestelltes „Bearer “, Anführungszeichen und Zeilenumbrüche entfernt das Tool selbst.

Ist mein Token hier sicher?

Dekodierung und Signaturberechnung laufen im Browser. Token und Geheimnis werden nicht gesendet, nicht gespeichert und nie in die URL übernommen. Echte Produktiv-Tokens solltest du trotzdem grundsätzlich nicht auf fremden Seiten einfügen.

Heißt „gültig“, dass das Token echt ist?

Nein. Die Anzeige bezieht sich nur auf die Zeitangaben und rechnet mit der Uhr deines Geräts. Ob der Inhalt echt und unverändert ist, zeigt allein die Signatur.

Sind Header und Payload verschlüsselt?

Nein, sie sind nur Base64url-kodiert. Jeder, der das Token besitzt, kann sie lesen. Deshalb gehören keine Geheimnisse wie Passwörter in die Payload.

Was bedeuten exp, nbf und iat?

Es sind Sekunden seit 1970-01-01 UTC. exp ist der Zeitpunkt, ab dem das Token ungültig ist, nbf der Zeitpunkt, vor dem es noch nicht gilt, und iat der Ausstellungszeitpunkt.

Welche Signaturen kann das Tool prüfen?

HS256, HS384 und HS512 (HMAC) mit dem gemeinsamen Geheimnis. RS-, PS-, ES- und EdDSA-Tokens brauchen den öffentlichen Schlüssel des Ausstellers und werden hier nicht geprüft. Header und Payload bleiben trotzdem lesbar.

Warum stimmt meine Signatur nicht?

Mögliche Gründe sind ein falsches Geheimnis, ein verändertes Token oder ein anders kodiertes Geheimnis. Ist das Geheimnis selbst Base64url-kodiert, hilft der entsprechende Schalter.

Was ist ein JWE mit fünf Teilen?

Ein JWT mit fünf Teilen ist ein verschlüsseltes Token (JWE). Sein Inhalt lässt sich ohne den Schlüssel nicht lesen, das Tool meldet das entsprechend.

Hintergrund

Ein JSON Web Token (JWT, RFC 7519) transportiert Aussagen, sogenannte Claims, in kompakter Form. Es besteht aus drei durch Punkte getrennten Teilen: Header, Payload und Signatur. Jeder Teil ist Base64url-kodiert, ohne Padding. Der Header nennt das Signaturverfahren im Feld alg, die Payload enthält die Claims, die Signatur sichert beides.

Typisch dient ein JWT als Login-Nachweis. Nach der Anmeldung stellt der Server ein Token aus, der Client schickt es bei jeder Anfrage mit, häufig im Header Authorization: Bearer. Der Server prüft die Signatur und die Zeitangaben, ohne den Zustand der Sitzung speichern zu müssen.

Wichtig ist der Unterschied zwischen Lesen und Prüfen. Header und Payload sind nur kodiert, nicht verschlüsselt. Wer das Token hat, kann den Inhalt lesen, wie es dieses Tool tut. Ob der Inhalt echt ist, entscheidet allein die Signatur. Verschlüsselte Tokens (JWE, RFC 7516) haben fünf Teile und sind ohne Schlüssel nicht lesbar.

Zu den registrierten Claims gehören iss (Aussteller), sub (Subjekt, oft eine Nutzer-ID), aud (Empfänger), jti (eindeutige Token-ID) sowie die Zeitangaben exp, nbf und iat. Diese Zeiten sind NumericDate-Werte: Sekunden seit dem 1. Januar 1970 UTC, nicht Millisekunden. Server erlauben oft eine kleine Toleranz, um Uhrenabweichungen auszugleichen.

Bei den Signaturverfahren unterscheidet man zwei Familien. HS256, HS384 und HS512 sind HMAC-Verfahren: Aussteller und Prüfer teilen ein Geheimnis, wer prüfen kann, kann also auch fälschen. RS-, PS-, ES- und EdDSA-Verfahren nutzen ein Schlüsselpaar, signiert wird mit dem privaten, geprüft mit dem öffentlichen Schlüssel.

Typische Sicherheitsfehler sind das Akzeptieren von alg „none“ (unsigniertes Token), die Übernahme des Verfahrens aus dem Token statt aus der Server-Konfiguration (Verwechslung von RS256 und HS256), schwache Geheimnisse, fehlendes exp, das Laden von Schlüsseln aus Header-Feldern wie jku oder jwk sowie Tokens in URLs oder Logs. Der Parser weist auf mehrere dieser Punkte hin und kann ein Token gegen eine Liste gängiger Standardgeheimnisse testen. Das ist ein Warntest, kein Knacken.