JWT Decoder & Inspector

JWT Decoder & Inspector: Token verstehen

JSON Web Tokens (JWT) stecken in so gut wie jeder modernen API und in vielen Login-Abläufen. Sie sehen oft aus wie ein sinnloser Zeichenbrei, enthalten aber Header und Payload im Klartext. Dieser JWT Decoder zerlegt dein Token in seine drei Teile, dekodiert Header und Payload und zeigt dir die darin enthaltenen Claims direkt als lesbares JSON, inklusive einer verständlichen Darstellung der Zeitstempel wie exp und iat. Alles passiert direkt in deinem Browser, dein Token wird dabei nicht an unseren Server übertragen.

Spezifikation: Der Aufbau eines JWT (RFC 7519)

Ein JWT ist definiert in RFC 7519. Es besteht aus drei durch Punkte getrennten, base64url-kodierten Teilen im Format Kopf.Payload.Signatur:

• Header: enthält den Algorithmus (alg, z. B. HS256) und den Typ (typ).
• Payload: enthält die eigentlichen Claims, etwa sub (Betreff), name, iat (Ausgabezeit) und exp (Ablaufzeit).
• Signatur: sichert die Integrität. Hinweis: Dieser Decoder prüft die Signatur nicht, er zeigt nur den dekodierten Inhalt.

Die drei Teile sind base64url-kodiert, also JSON als reiner Text. Das bedeutet: Jeder, der das Token besitzt, kann Header und Payload lesen – ein JWT ist keine Verschlüsselung, sondern ein signiertes, lesbares Format.

Ein durchgerechnetes Beispiel. Dieses (echt erzeugte und verifizierbare) Token nutzt HS256:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwODY0MDB9.lH5ouZL2oVqxvPKH6npv5cBimEhFEGSRLmDh3XItZYE

Der erste Teil dekodiert zu {"alg":"HS256","typ":"JWT"}, der zweite zu {"sub":"1234567890","name":"Jane Doe","iat":1700000000,"exp":1700086400}. Der dekodierte Inspector zeigt iat (14.11.2023 22:13:20 UTC) und exp (15.11.2023 22:13:20 UTC) als lesbare Daten sowie einen Statushinweis, ob das Token noch gültig oder abgelaufen ist.

Der Algorithmus im Header: HS256 vs. RS256

Der alg-Header nennt das Signaturverfahren. HS256 ist ein symmetrisches Verfahren (HMAC-SHA-256): Aussteller und Empfänger teilen sich ein einziges geheimes Passwort. RS256 ist asymmetrisch (RSA): Der Aussteller signiert mit seinem privaten Schlüssel, jeder kann mit dem öffentlichen Schlüssel prüfen. Das Tool zeigt dir den Algorithmus an, verifiziert aber selbst nichts.

Kritisch: Dekodieren ist nicht Verifizieren

Das ist der wichtigste Punkt überhaupt: Ein Token lesen zu können heißt nicht, dass es authentisch ist. Die Dekodierung liest nur den Klartext von Header und Payload. Ob die Signatur wirklich stimmt, ist eine ganz andere, separate Prüfung. Dazu brauchst du den korrekten Schlüssel des Ausstellers: den geteilten Secret bei HS256 oder den öffentlichen Schlüssel bei RS256. Ohne diesen Schlüssel gibt es kein verlässliches Verifikationsergebnis. Vertraue einem Token daher niemals nur weil es sich dekodieren lässt, und ignoriere niemals die Signaturprüfung.

• Signatur ist der Beweis der Integrität: Nur wenn die Signatur mit dem richtigen Schlüssel geprüft wird, weißt du, dass der Inhalt nicht manipuliert wurde.
• Nie blind vertrauen: Vertraue Feldern wie kid oder alg nicht, bevor du die Signatur gegen eine vertrauenswürdige Schlüsselquelle verifiziert hast. Manipulierte Header könnten sonst den Algorithmus umschreiben wollen.
• Lokal bedeutet nur lokal: Dass dieses Tool das Token lokal dekodiert, sagt nichts über dessen Gültigkeit aus, sondern nur, dass deine Daten nicht an einen Server gehen.

Die standardisierten Claims

RFC 7519 definiert einige Claim-Namen mit fester Bedeutung, die du beim Dekodieren regelmäßig siehst:

• iss – der Aussteller (Issuer) des Tokens
• sub – der Betreff, also wem das Token zugeordnet ist
• aud – die Zielgruppe (Audience), für die es bestimmt ist
• exp – die Ablaufzeit als Unix-Sekunden
• nbf – der früheste Zeitpunkt, ab dem es gültig ist
• iat – der Ausgabezeitpunkt
• jti – eine eindeutige ID des Tokens

Viele dieser Werte sind Zeitstempel, die der Inspector automatisch in lesbare Daten umwandelt.

Wann gilt ein JWT als ungültig?

Ein Token gilt als nicht (mehr) gültig, wenn es abgelaufen ist (exp erreicht), noch nicht aktiv ist (nbf in der Zukunft), die Audience nicht passt oder die Signatur nicht mit dem erwarteten Schlüssel verifiziert werden kann. Die Zeitprüfungen kann jeder durchführen; die Integritäts- und Herkunftsprüfung setzt den richtigen Schlüssel voraus. Dieser Decoder zeigt dir den Zeitstatus, kann die Schlüsselprüfung aber nicht ersetzen.

Häufige Fragen