JWT-Decoder
JWT-Header, Payload und Ablauf untersuchen.
Über dieses Tool
Dekodiere ein JSON Web Token, um seinen Header und seine Claims zu lesen. Zeitstempel wie exp, iat und nbf werden als lesbares Datum angezeigt, und du siehst auf einen Blick, ob das Token abgelaufen ist. Die Signatur wird nicht geprüft.
So verwendest du es
- Füge ein JSON Web Token ein. Ein vorangestelltes „Bearer “ wird automatisch entfernt.
- Lies den dekodierten Header und die Payload.
- Am Status-Banner und an den Zeit-Claims siehst du, wann das Token ausgestellt wurde und wann es abläuft.
Fragen
- Prüft das die Signatur?
- Nein. Es dekodiert das Token nur. Zum Prüfen braucht es das Secret oder den öffentlichen Schlüssel, und das sollte auf deinem Server passieren. Vertraue einem Token nie, nur weil es sich dekodieren lässt.
- Kann ich hier gefahrlos ein echtes Token einfügen?
- Das Dekodieren passiert komplett in deinem Browser, und das Token wird nirgendwohin gesendet. Behandle Produktions-Tokens trotzdem wie Passwörter und nimm wenn möglich abgelaufene oder Test-Tokens.
- Was bedeuten exp, iat und nbf?
- exp ist der Zeitpunkt, an dem das Token abläuft, iat der Ausstellungszeitpunkt und nbf der Zeitpunkt, vor dem es nicht akzeptiert werden darf. Alle drei sind Unix-Zeitstempel in Sekunden.
- Kann jeder den Inhalt eines JWT lesen?
- Ja. Header und Payload sind nur Base64url-kodiert, nicht verschlüsselt. Pack keine Geheimnisse oder sensiblen personenbezogenen Daten in die Payload eines JWT.
- Warum hat mein Token fünf Teile statt drei?
- Ein Token aus fünf durch Punkte getrennten Teilen ist ein JWE, ein verschlüsseltes JSON Web Token nach RFC 7516. Seine Payload lässt sich ohne den Entschlüsselungsschlüssel nicht lesen, deshalb meldet dieser Decoder einen Fehler. Ein Token mit nur zwei Teilen wurde meist beim Kopieren abgeschnitten; selbst ein unsigniertes Token behält einen abschließenden Punkt.
- Was ist kid im JWT-Header?
- kid ist die Key-ID. Sie sagt dem Prüfer, welchen Schlüssel er verwenden soll, wenn der Aussteller mehrere veröffentlicht, etwa in einem JWKS-Dokument. Das ermöglicht Schlüsselrotation: Neue Tokens werden mit einem neuen Schlüssel signiert, während mit dem alten signierte Tokens gültig bleiben, bis sie ablaufen.
- Kann ich die Payload eines JWT bearbeiten und es weiter verwenden?
- Du kannst die Payload ändern und neu kodieren, aber dann passt die Signatur nicht mehr, und ein korrekt konfigurierter Server lehnt das Token ab. Wird ein bearbeitetes Token akzeptiert, prüft der Server keine Signaturen – eine ernste Sicherheitslücke, die du sofort melden oder beheben solltest.
Was ist ein JWT und wie ist es aufgebaut?
Ein JSON Web Token, definiert in RFC 7519, ist ein kompakter String aus drei durch Punkte getrennten Teilen: Header, Payload und Signatur. Der Header gibt an, wie das Token signiert ist, mit einem alg-Wert wie HS256 oder RS256. Die Payload enthält die Claims: um wen es im Token geht (sub), wer es ausgestellt hat (iss), für wen es bestimmt ist (aud) und wann es abläuft (exp). Beide Teile sind JSON, kodiert mit base64url.
Der dritte Teil ist die Signatur, berechnet über die ersten beiden mit einem Secret oder einem privaten Schlüssel. Weil der Header JSON ist und mit einer geschweiften Klammer und einem doppelten Anführungszeichen beginnt, fängt fast jedes JWT mit eyJ an – daran erkennst du es in Logs und Request-Headern. Füge ein Token in diesen JWT-Decoder ein, um Header und Payload formatiert zu sehen, mit Zeit-Claims als Datum.
Warum wird mein JWT abgelehnt, obwohl es sich dekodieren lässt?
Auch ein Token, das sich sauber dekodieren lässt, kann abgelehnt werden, meist mit einem 401. Die häufigste Ursache ist der Ablauf, prüfe also das Status-Banner, das dir sagt, ob exp schon in der Vergangenheit liegt. Denk daran, dass exp in Sekunden angegeben ist: Ein Backend, das es mit einer JavaScript-Zeit in Millisekunden vergleicht, entscheidet falsch. Auch Zeitabweichungen zwischen Servern spielen eine Rolle, deshalb erlauben die meisten Bibliotheken eine kleine Toleranz.
Stimmen die Zeiten, vergleiche die Claims mit dem, was der Server erwartet. Ein aud, das nicht zur API passt, ein unerwarteter iss oder ein Token von einem Staging-Identity-Provider, das an die Produktion geschickt wird, fallen alle bei der Validierung durch. Eine Signaturprüfung schlägt fehl, wenn der Schlüssel falsch ist, das Token bearbeitet wurde oder das alg im Header keines ist, das der Server akzeptiert. Dieser Decoder prüft keine Signaturen und kann dir daher nicht sagen, welcher dieser Fälle zutrifft.
HS256 vs. RS256: Welchen JWT-Algorithmus nehmen?
HS256 signiert das Token mit HMAC-SHA256 und einem gemeinsamen Secret. Jeder Dienst, der Tokens prüft, braucht genau dieses Secret, mit dem er aber auch neue Tokens erstellen kann. Für ein einzelnes Backend ist das in Ordnung, über viele Dienste hinweg riskant. RS256 (RSA) und ES256 (ECDSA) nutzen stattdessen ein Schlüsselpaar: Der Aussteller signiert mit einem privaten Schlüssel, alle anderen prüfen mit dem öffentlichen, der oft an einem JWKS-Endpunkt veröffentlicht wird.
Egal, wofür du dich entscheidest: Lege den erlaubten Algorithmus auf der prüfenden Seite fest, statt dem alg-Feld im Header zu vertrauen. Ein Token mit alg auf none hat überhaupt keine Signatur und muss immer abgelehnt werden. Halte exp kurz, eher Minuten als Tage, und nutze Refresh-Tokens für längere Sitzungen. alg und kid kannst du hier im Header-Bereich ablesen, und jeden Zeitstempel prüfst du mit dem Unix-Zeitstempel-Konverter.
Funktioniert etwas nicht, oder sieht ein Ergebnis falsch aus? Ein Problem mit diesem Tool melden