Über den JWT Decoder
Dieser kostenlose JWT-Decoder liest ein JSON Web Token und zeigt dessen Header und Payload als formatiertes JSON an, wobei die Ausstellungs- und Ablaufzeiten in lesbare Datumsangaben umgewandelt werden.
Die Dekodierung erfolgt in Ihrem Browser — Ihr Token wird niemals hochgeladen. Das ist kein Nebenaspekt: Ein JWT ist in der Regel eine aktive Zugangsberechtigung, und wer eines in eine Website einfügt, die es irgendwohin sendet, gibt damit sämtliche darin enthaltenen Zugriffsrechte preis.
Dieses Werkzeug dekodiert ein Token. Es überprüft die Signatur nicht — weiter unten erfahren Sie, warum dieser Unterschied wichtig ist.
Die drei Teile eines Tokens
Ein JWT besteht aus drei durch Punkte getrennten Base64url-Abschnitten:
xxxxx.yyyyy.zzzzz
Header — welcher Algorithmus das Token signiert hat und um welchen Typ es sich handelt. Üblicherweise zwei Felder: alg und typ.
Payload — die Claims. Wen das Token betrifft, wer es ausgestellt hat, wann es abläuft und was die Anwendung sonst noch hineingelegt hat: Benutzer-ID, E-Mail, Rollen, Berechtigungen, Mandant.
Signatur — eine kryptografische Prüfung über die ersten beiden Teile, erstellt mit einem Geheimnis oder einem privaten Schlüssel. Sie belegt, dass das Token seit der Ausstellung nicht verändert wurde.
Das Entscheidende dabei: Die ersten beiden Teile sind nicht verschlüsselt. Sie sind lediglich kodiert, und jeder kann sie lesen. Fügen Sie ein Token auf dieser Seite ein, und sein Inhalt erscheint sofort. Base64url ist eine Methode, Daten sicher in eine URL oder einen Header zu setzen, keine Methode, sie zu verbergen.
Was das für den Inhalt eines Tokens bedeutet
Da die Payload für jeden lesbar ist, der das Token besitzt, folgt daraus unmittelbar die Regel: Legen Sie niemals etwas Geheimes in ein JWT.
Was nicht in eine Payload gehört: Passwörter, API-Schlüssel, Kreditkartendaten, Ausweisnummern, medizinische Informationen, alles, was unter Datenschutzrecht fällt. All das ist für den Benutzer lesbar, für alles, was die Anfrage protokolliert, und für jeden, der das Token erlangt.
Was hineingehört: eine Benutzer-ID, eine Rolle, ein Ablaufdatum, ein Aussteller, eine Zielgruppe — Kennungen und Claims, die für das empfangende System sichtbar sein sollen.
Die Signatur schützt die Integrität, nicht die Vertraulichkeit. Sie garantiert, dass niemand das Token verändert hat. Sie hindert niemanden daran, es zu lesen.
Dekodieren ist nicht Verifizieren
Dies ist der Unterschied, der echte Sicherheitslücken verursacht, deshalb lohnt sich hier Genauigkeit.
Dekodieren entpackt das Base64url und zeigt Ihnen das JSON. Es benötigt keinen Schlüssel, jeder kann es tun, und es beweist überhaupt nichts darüber, ob das Token echt ist.
Verifizieren berechnet die Signatur mit dem Geheimnis oder dem öffentlichen Schlüssel neu und prüft, ob sie übereinstimmt. Nur das sagt Ihnen, dass das Token wirklich von dem angegebenen Aussteller stammt und nicht manipuliert wurde.
Ein Token kann sich einwandfrei dekodieren lassen und trotzdem eine vollständige Fälschung sein. Jeder kann ein JWT erstellen, das "role": "admin" enthält, und es wird hier wunderbar angezeigt — denn Anzeigen ist alles, was hier geschieht.
Dieses Werkzeug verifiziert bewusst nicht, und das ist die sichere Wahl: Die Verifizierung erfordert das Signaturgeheimnis, und Ihr Signaturgeheimnis in eine Webseite einzufügen wäre weit gefährlicher als ein Token. Die Verifizierung gehört auf Ihren Server, mit Ihrem Schlüssel, mit einer geeigneten Bibliothek.
Die historische Ausprägung dieses Fehlers ist der alg: none-Angriff. Frühe JWT-Bibliotheken akzeptierten einen Header, der behauptete, es sei kein Algorithmus verwendet worden, und nahmen das Token unverifiziert an. Ein Angreifer konnte die Payload bearbeiten, alg auf none setzen und einfach hineinspazieren. Moderne Bibliotheken lehnen das ab, aber genau deshalb sollten Sie den erwarteten Algorithmus immer fest vorgeben, statt dem Header zu vertrauen.
Die Standard-Claims lesen
Die meisten kurzen Feldnamen in einer Payload sind registrierte Claims mit festgelegter Bedeutung:
- exp — Ablaufzeit. Danach sollte das Token abgelehnt werden.
- iat — issued at, ausgestellt am. Wann es erstellt wurde.
- nbf — not before, nicht vor. Das Token ist bis zu diesem Zeitpunkt ungültig.
- sub — Subjekt. Normalerweise die Benutzer-ID.
- iss — Aussteller. Wer das Token erstellt hat.
- aud — Zielgruppe. Für welchen Dienst es bestimmt ist.
- jti — Token-ID, verwendet für Sperrlisten.
exp, iat und nbf sind Unix-Zeitstempel — Sekunden seit dem 1. Januar 1970 — weshalb sie wie eine bedeutungslose zehnstellige Zahl aussehen. Dieses Werkzeug wandelt sie in lesbare Datumsangaben um, was meist der schnellste Weg ist, die Frage zu beantworten, die Sie hierhergeführt hat: *Ist dieses Token abgelaufen?*
So verwenden Sie es
- Fügen Sie Ihr JWT ein (die Zeichenkette xxxxx.yyyyy.zzzzz)
- Lesen Sie den dekodierten Header und die Payload unten
- Kopieren Sie einen der beiden Teile, wenn Sie ihn brauchen
Gut zu wissen
- Behandeln Sie ein Token wie ein Passwort. Solange es gültig ist, kann jeder, der es besitzt, als dieser Benutzer handeln. Fügen Sie keine aktiven Token in Werkzeuge ein, die sie hochladen, und posten Sie sie nicht in einem Ticket oder Chat.
- JWTs lassen sich schwer widerrufen. Sie sind bis zum Ablauf gültig, ein gestohlenes Token funktioniert also bis dahin, sofern Sie keine Sperrliste pflegen. Deshalb sind kurze Ablaufzeiten wichtig.
- Bearer gehört nicht zum Token. Entfernen Sie dieses Präfix aus einem Authorization-Header vor dem Dekodieren.
- Base64url ist nicht Standard-Base64. Es verwendet - und _ statt + und / und lässt die =-Auffüllung meist weg, weshalb ein JWT-Abschnitt in einem einfachen Base64-Decoder scheitern kann.
- Zeitabweichungen verursachen verwirrende Fehler. Ein Token kann für Sie gültig aussehen und von einem Server abgelehnt werden, dessen Uhr ein oder zwei Minuten abweicht.
- Ein JWT ist keine Sitzung. Es trägt seine Claims mit sich, Änderungen an der Rolle eines Benutzers werden also erst wirksam, wenn das Token abläuft.
Häufige Fragen
Ist ein JWT verschlüsselt?
Nein. Header und Payload sind Base64url-kodiert, was sie sicher für eine URL oder einen HTTP-Header macht, sie aber keineswegs verbirgt. Jeder, der das Token besitzt, kann jeden Claim darin lesen, wie diese Seite zeigt. Die Signatur schützt das Token davor, verändert zu werden, nicht davor, gelesen zu werden.
Überprüft dieses Werkzeug die Signatur?
Nein, und das mit Absicht. Die Verifizierung erfordert das Signaturgeheimnis oder den öffentlichen Schlüssel, und Ihr Signaturgeheimnis in eine Webseite einzufügen wäre erheblich gefährlicher als ein Token. Die Verifizierung gehört mit einer geeigneten Bibliothek auf Ihren Server. Dieses Werkzeug dekodiert und zeigt Ihnen den Inhalt, und genau das brauchen Sie bei der Fehlersuche.
Ist es sicher, mein Token hier einzufügen?
Hier ja — die Dekodierung findet vollständig in Ihrem Browser statt und nichts wird übertragen, Sie können also die Internetverbindung trennen und es funktioniert weiterhin. Seien Sie bei Werkzeugen aber generell vorsichtig. Ein aktives JWT ist eine funktionierende Zugangsberechtigung, und eine Website, die es an einen Server sendet, hat gerade alle damit verbundenen Rechte erhalten.
Wie erkenne ich, ob mein Token abgelaufen ist?
Sehen Sie sich den exp-Claim an, einen Unix-Zeitstempel in Sekunden. Dieses Werkzeug wandelt ihn in ein lesbares Datum um und sagt Ihnen direkt, ob der Zeitpunkt vorüber ist. Wenn ein Token für Sie gültig aussieht, ein Server es aber ablehnt, prüfen Sie die Zeitabweichung — ein Unterschied von ein bis zwei Minuten zwischen Rechnern genügt.
Was bedeuten sub, iss, aud und iat?
Es sind registrierte Claims mit standardisierter Bedeutung: sub ist das Subjekt, normalerweise die Benutzer-ID; iss ist der Aussteller, der das Token erstellt hat; aud ist die vorgesehene Zielgruppe, also welcher Dienst es annehmen soll; iat ist der Zeitpunkt der Ausstellung. Zusammen mit exp und nbf decken sie Wer, Wo und Wann ab.
Warum scheitert mein JWT in einem normalen Base64-Decoder?
Weil ein JWT Base64url verwendet, eine Variante, die + durch - und / durch _ ersetzt und die =-Auffüllung meist entfernt. Diese Ersetzungen gibt es, damit der Wert innerhalb einer URL sicher ist. Tauscht man die Zeichen zurück, lässt er sich in einem Standard-Base64-Werkzeug dekodieren.
Kann ich eine JWT-Payload bearbeiten?
Sie können den Text ändern, aber das Ergebnis wird von jedem korrekt implementierten Server abgelehnt, weil die Signatur nicht mehr zum veränderten Inhalt passt. Genau dafür ist die Signatur da. Token werden von dem Dienst neu ausgestellt, der sie signiert, nicht von Hand bearbeitet.
Verwandte Werkzeuge
- Base64 kodieren / dekodieren — die Kodierung, in der die drei Abschnitte geschrieben sind
- JSON-Formatierer — die dekodierte Payload aufräumen und prüfen
- Hash-Generator — die Hash-Funktionen unter der Signatur
