JSON-Formatierer
JSON formatieren, prüfen und minifizieren, mit genauer Fehlerstelle.
Entwicklung
JWT-Decoder
Header, Payload und Claims lesen, ohne den Token zu senden.
Was es macht. Ein JSON Web Token besteht aus drei durch Punkte getrennten Teilen: Header, Payload und Signatur. Header und Payload sind lediglich Base64-kodiert, also für jeden lesbar, der den Token hat. Dieses Werkzeug dekodiert sie in deinem Browser — der Token wird nicht übertragen.
Läuft im BrowserKein UploadKeine AnmeldungFunktioniert offline
So benutzt du JWT-Decoder
- Füg den Token ein. Die drei Teile werden sofort dekodiert.
- Lies im Header das Signaturverfahren und im Payload die Claims.
- Prüf im Ablauf-Feld, ob der Token derzeit gültig ist.
Produktive Tokens gehören nicht in eine Website
Ein Zugriffstoken ist ein Anmeldeausweis. Wer ihn hat, kann bis zum Ablauf handeln wie der Nutzer, dem er gehört.
Die bekanntesten JWT-Werkzeuge im Netz senden den Token an einen Server — teils zur Signaturprüfung, teils weil das Formular schlicht abgeschickt wird. Damit liegt ein gültiger Ausweis bei einem Dritten, und wer ihn dort protokolliert, hat einen funktionierenden Zugang.
Dieses Werkzeug dekodiert ausschließlich lokal. Überprüfen lässt sich das im Netzwerk-Tab der Entwicklerwerkzeuge: Beim Einfügen erscheint keine Anfrage. Ist ein Token dennoch einmal irgendwo eingefügt worden, sollte er als kompromittiert gelten und zurückgezogen werden.
Was in den drei Teilen steht
Header und Payload sind JSON, nur Base64-kodiert. Die Signatur ist das einzige, was Sicherheit schafft.
| Teil | Inhalt | Lesbar für jeden? |
|---|---|---|
| Header | Verfahren (alg) und Typ (typ) | Ja |
| Payload | Claims: sub, exp, iat, iss, aud, eigene Felder | Ja |
| Signatur | HMAC oder Signatur über die ersten beiden Teile | Nur prüfbar, nicht lesbar |
Die üblichen Claims: sub die Kennung des Subjekts, exp der Ablaufzeitpunkt als Unix-Zeit, iat der Ausstellungszeitpunkt, iss der Aussteller, aud das Zielpublikum. Weil Payload-Inhalte offen lesbar sind, gehören personenbezogene Daten nur hinein, wenn sie ohnehin unproblematisch sind — und schon gar keine Passwörter.
Dekodiert ist nicht geprüft
Ein dekodierter Token sagt nur, was jemand behauptet. Ob die Behauptung stimmt, entscheidet allein die Signatur.
Zum Prüfen braucht es den Schlüssel: bei HMAC-Verfahren das gemeinsame Geheimnis, bei RSA oder ECDSA den öffentlichen Schlüssel des Ausstellers. Beides gehört auf den Server, nicht in ein Browser-Werkzeug — deshalb prüft dieses hier nicht.
Historisch gab es dazu eine berüchtigte Schwachstelle: Bibliotheken, die dem Feld alg im Header vertrauten, ließen sich mit alg: none überreden, jede Signatur zu akzeptieren. Aktuelle Bibliotheken verlangen deshalb, dass die Serverseite das erwartete Verfahren vorgibt, statt es dem Token zu entnehmen.
Häufige Fragen
Ist ein JWT verschlüsselt?
Nein. Header und Payload sind nur Base64-kodiert und für jeden lesbar. Die Signatur schützt vor Änderung, nicht vor Einsicht.
Wird mein Token gesendet?
Nein. Das Dekodieren läuft in diesem Tab, überprüfbar im Netzwerk-Tab.
Könnt ihr die Signatur prüfen?
Nein, dafür wäre der Schlüssel nötig. Der gehört auf den Server, nicht in ein Browser-Werkzeug.
Was bedeutet exp?
Den Ablaufzeitpunkt als Unix-Zeit in Sekunden. Das Werkzeug rechnet ihn in Datum und Uhrzeit um.
Darf ich personenbezogene Daten in den Payload legen?
Nur solche, die offen liegen dürfen. Der Payload ist für jeden lesbar, der den Token besitzt.
Was ist die alg-none-Lücke?
Eine alte Schwachstelle, bei der Bibliotheken dem Verfahren im Header vertrauten und dadurch jede Signatur akzeptierten.
Ratgeber zu JWT-Decoder
- Base64, URL Encoding and JWTs7 min read
- MD5 vs SHA-256, and Verifying a Download6 min read