JWT-Decoder
Läuft komplett in deinem Browser. Deine Dateien und Daten verlassen dein Gerät nie.
- iat: 2018-01-18T01:30:22.000Z
Über dieses Tool
Ein JSON Web Token besteht aus drei durch Punkte getrennten, Base64Url-kodierten Segmenten: einem Header, der den Signaturalgorithmus beschreibt, einem Payload mit den Claims und einer Signatur. Header und Payload sind nur kodiert, nicht verschlüsselt, wer das Token in der Hand hat, kann sie also lesen. Dieses Tool dekodiert beide sofort. Das Format ist in RFC 7519 festgelegt.
Was sehe ich, wenn ich ein Token einfüge?
Ein Token einfügen zeigt Header und Payload als formatiertes JSON, dazu einen Klartext-Hinweis zu jedem zeitbasierten Claim, den das Token enthält. Der Header nennt meist den Signaturalgorithmus (alg) und den Token-Typ. Der Payload trägt, was der Aussteller hineingelegt hat: die üblichen Claims wie Aussteller (iss), Subjekt (sub), Empfänger (aud), Ablaufzeit (exp), Ausstellungszeit (iat), Gültig-ab (nbf), dazu alle benutzerdefinierten Claims, die ein Anbieter ergänzt, etwa Rollen oder Scopes. Bei exp, iat und nbf rechnet das Tool den Unix-Zeitstempel zusätzlich in ein lesbares Datum um und sagt dir, ob das Token abgelaufen oder noch nicht gültig ist, meist der schnellste Weg herauszufinden, warum eine API es abgelehnt hat. Ein Token braucht genau drei durch Punkte getrennte Teile mit gültigem Base64Url-kodiertem JSON in den ersten beiden, sonst meldet das Tool ein ungültiges JWT.
Wird mein Token irgendwohin gesendet?
Nein. Die Dekodierung läuft vollständig im Browser: Das Token wird lokal zerlegt und geparst, nichts geht über das Netzwerk. Deshalb lassen sich auch echte Access-Tokens aus einem Produktivsystem hier gefahrlos einfügen, ohne dass sie einen Drittanbieter durchlaufen.
Prüft dieses Tool die Signatur?
Nein, und das ist wichtig. Das Tool dekodiert nur Header und Payload, das heißt Base64Url dekodieren und als JSON parsen, mehr nicht. Die Signatur wird nicht geprüft, das Tool kann also nicht sagen, ob ein Token echt ist oder manipuliert wurde. Dekodieren zeigt, was ein Token behauptet, verifizieren beweist, dass diese Behauptungen stimmen, und dieser Check muss gegen den Signaturschlüssel des Ausstellers laufen, normalerweise auf einem Server oder in einer Backend-Bibliothek mit Zugriff darauf. Beim Debuggen eines abgelehnten Tokens hilft das Dekodieren hier, schnell zu sehen, ob die Claims plausibel aussehen, ein erfolgreiches Dekodieren ist aber nicht dasselbe wie eine gültige Signatur.
Wie die drei Segmente zusammenspielen und was die einzelnen Standard-Claims bedeuten, erklärt neben der RFC auch Auth0s Einführung zu JWT.