JWT Token decodieren: Claims sicher im Browser lesen

Wenn du schon einmal auf eine lange Zeichenkette wie eyJhbGciOi... in einer API-Antwort gestarrt und dich gefragt hast, was da eigentlich drinsteht, bist du nicht allein. Zu lernen, wie man einen JWT Token decodieren kann, gehört zu den nützlichsten Debugging-Fähigkeiten, die ein Entwickler erwerben kann – und es dauert etwa dreißig Sekunden, sobald man den Trick kennt. Ein JSON Web Token (JWT) sieht aus wie zufälliges Kauderwelsch, besteht aber in Wirklichkeit aus drei lesbaren Teilen, die mit Punkten verbunden sind. In dieser Anleitung erfährst du, was in jedem Teil steckt, wie du einen Token sicher in deinem Browser decodierst, ohne etwas zu installieren, und welchen Sicherheitsfehler du beim Prüfen von Tokens unbedingt vermeiden musst.

Was ein JWT tatsächlich enthält

Ein JWT ist eine kompakte, URL-sichere Art, Informationen zwischen zwei Parteien zu übertragen – meist zwischen einem Server und einem Browser oder einer mobilen App, nachdem sich ein Nutzer angemeldet hat. Bei erfolgreicher Authentifizierung erstellt der Server einen Token voller Claims: kleine Aussagen wie „dies ist Nutzer 42“, „dieser Token wurde um 15 Uhr ausgestellt“ und „er läuft in einer Stunde ab“. Der Client sendet diesen Token dann bei jeder Anfrage zurück, üblicherweise im Authorization-Header, damit der Server weiß, wer da fragt.

Und hier kommt der Punkt, der die meisten Anfänger überrascht: Ein Standard-JWT ist signiert, nicht verschlüsselt. Jeder, der die Token-Zeichenkette besitzt, kann die Payload lesen – ganz ohne geheimen Schlüssel. Die Signatur beweist nur, dass der Token von jemandem stammt, der den Schlüssel (oder privaten Schlüssel) besitzt, und dass er nicht manipuliert wurde. Lesen und Vertrauen sind zwei verschiedene Dinge, und genau diese Verwechslung verursacht die meisten JWT-Sicherheitsfehler.

Weil der Token die Nutzerdaten trägt, können Server Anfragen prüfen, ohne jedes Mal die Datenbank abzufragen – aber das macht den Token auch zu einer Bearer-Credential, einer Art temporärem Passwort. Wer ihn besitzt, kann sich bis zum Ablauf als der Nutzer ausgeben. Gehe also sorgsam mit echten Tokens um.

Header, Payload, Signatur: Die drei Teile

Jede Anleitung zum Thema JWT Token decodieren beginnt mit derselben Anatomie, denn die Struktur ändert sich nie: header.payload.signature – drei Base64URL-codierte Segmente, getrennt durch Punkte, darunter jeweils schlichtes JSON.

1. Header. Ein kleines JSON-Objekt, das den Token selbst beschreibt, fast immer mit zwei Feldern: typ ("JWT") und alg, dem Signieralgorithmus, zum Beispiel HS256 (HMAC mit SHA-256) oder RS256 (RSA mit SHA-256). Ein typischer decodierter Header:

{"alg": "HS256", "typ": "JWT"}

2. Payload. Die Payload enthält die Claims – die eigentlichen Daten. Claims sind registriert (die Standardfelder iss, sub, aud, exp, nbf, iat, jti), öffentlich (eigene Namen, die zur Vermeidung von Kollisionen registriert werden) oder privat (alles, worauf sich Aussteller und Empfänger einigen, zum Beispiel eine Nutzerrolle). Das klassische Beispiel:

{"sub": "1234567890", "name": "Jane Doe", "iat": 1516239022}

3. Signatur. Die Signatur entsteht, indem der codierte Header, ein Punkt und die codierte Payload gemeinsam signiert werden – mit HMAC lautet das HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret); mit RSA signiert der Aussteller mit seinem privaten Schlüssel. Alles ist Base64URL-codiert – einer URL-sicheren Base64-Variante, die + durch - und / durch _ ersetzt – damit Tokens problemlos in URLs und Headern überleben.

So decodierst du einen Token sicher in deinem Browser

Jetzt zum praktischen Teil: Wie du einen JWT Token decodieren kannst, ohne Software zu installieren. Du hast drei gute Optionen, und die sichersten senden deinen Token niemals an einen Server.

Option 1: ein clientseitiger Decoder. Der einfachste Weg ist ein kostenloser JWT-Decoder, der komplett in deinem Browser läuft – Token einfügen, und Header und Payload erscheinen sofort als lesbares JSON. Das Decodieren passiert lokal in JavaScript, der Token verlässt also nie deinen Rechner: kein Upload, kein Server-Log, nichts, was durchsickern könnte.

Option 2: deine Browser-Konsole. Lieber per Tastatur? Öffne die DevTools und führe diesen Einzeiler aus – er wandelt Base64URL zuerst zurück in Standard-Base64:

JSON.parse(atob(token.split('.')[1].replace(/-/g,'+').replace(/_/g,'/')))

Das schneidet das mittlere Segment heraus, tauscht die URL-sicheren Zeichen zurück, decodiert es mit atob() und parst das JSON. Es liest nur die Payload – es prüft die Signatur nicht, was zum Inspizieren völlig reicht, aber du solltest die Inhalte deshalb nicht als vertrauenswürdig behandeln.

Option 3: eine Debugger-Seite. Debugger-Seiten wie jwt.io decodieren Tokens ebenfalls in deinem Browser und lassen dich die Signaturprüfung mit einem Secret testen. Sie funktionieren, aber für einen schnellen Blick nimm lieber ein schlankes Tool, dem du vertraust – füge den Token in Toolingas JWT-Decoder ein, wenn du einfach schnell Antworten willst.

Merke dir: Decodieren ist nicht Verifizieren. Decodieren liest die Payload; Verifizieren prüft die Signatur, wofür du das Secret (HMAC) oder den öffentlichen Schlüssel (RSA) brauchst. Ein Decoder zeigt dir bereitwillig eine Payload mit ungültiger Signatur an. Vertraue einem Token niemals, nur weil es sich sauber decodieren ließ.

Die wichtigsten Claims erklärt (exp, iat, sub)

Wenn du Tokens decodieren kannst, ist der nächste Schritt zu verstehen, was die Standard-Claims bedeuten. Diese drei begegnen dir in fast jedem Token:

• exp – Ablaufzeitpunkt (expiration time). Der Moment, ab dem der Token nicht mehr akzeptiert werden darf. Es ist ein NumericDate: die Anzahl der Sekunden seit der Unix-Epoche (1970-01-01T00:00:00Z). Wenn exp den Wert 1760500000 hat, stirbt der Token in genau dieser Sekunde. Wenn deine App plötzlich „Token abgelaufen“-Fehler wirft, ist Decodieren und exp lesen die schnellste Diagnose – die Zahl lässt sich mit jedem Epoch-Konverter oder mit new Date(1760500000 * 1000) in der Konsole umrechnen.
• iat – Ausstellungszeitpunkt (issued at). Wann der Token erstellt wurde, im selben NumericDate-Format. Der Vergleich von iat und exp zeigt dir auf einen Blick die Lebensdauer des Tokens – praktisch, wenn du eine falsch konfigurierte Ablaufzeit vermutest (zum Beispiel Tokens, die ein Jahr lang leben, weil jemand Tage statt Sekunden eingetippt hat).
• sub – Subjekt (subject). Um wen es im Token geht – meist eine Nutzer-ID wie "sub": "user_8f42". Wenn sich Anfragen so verhalten, als gehörten sie zum falschen Konto, verrät dir ein Blick auf sub sofort, ob der Token selbst das Problem ist oder etwas Weiteres in der Kette.

Außerdem begegnen dir iss (Aussteller), aud (Zielgruppe), nbf (nicht gültig vor diesem Zeitpunkt) und jti (eindeutige Token-ID, praktisch für Sperrlisten). Ein Tipp: Server erlauben bei exp meist ein paar Sekunden Zeitabweichung – jage also keinem Phantom wegen einer Sekunde Differenz hinterher.

Warum du Tokens niemals in zufällige Webseiten einfügen solltest

Hier kommt die Sicherheitslektion, die wichtiger ist als alles oben: Weil eine JWT-Payload nur codiert und nicht verschlüsselt ist, ist die Token-Zeichenkette selbst das Geheimnis. Wer sie kopiert, kann sie gegen die API abspielen und sich bis zum exp-Zeitpunkt als der Nutzer ausgeben. Einen echten Produktions-Token in einen Decoder einzufügen, der ihn an einen Server sendet – oder loggt, oder in einem geteilten Screenshot zeigt – übergibt deine Sitzung an denjenigen, der diesen Server kontrolliert.

Halte dich also an drei Regeln. Erstens: Decodiere mit Test-Tokens – nimm einen Dummy- oder abgelaufenen Token oder einen für einen Wegwerf-Testnutzer erstellten, bevor du ein neues Tool ausprobierst. Zweitens: bevorzuge Tools, die lokal decodieren – wenn die Seite offline funktioniert, hat dein Token deinen Rechner nie verlassen. Drittens: behandle jede mögliche Enthüllung als Kompromittierung – wenn ein echter Token durchgesickert sein könnte, widerrufe ihn sofort. Kurzlebige Access-Tokens existieren genau dafür, den Schaden zu begrenzen.

Token-Debugging findet selten isoliert statt – bei der Fehlersuche an der Authentifizierung starrst du meist gleichzeitig auf Datenbank-Query-Logs. Wenn du diese vorher durch einen SQL-Formatter jagst, wird die Sitzung deutlich weniger schmerzhaft. Halte die Schleife eng: Token decodieren, Claims lesen, Queries prüfen.

Ist das Decodieren eines JWT dasselbe wie das Verifizieren?

Nein. Decodieren wandelt die Payload aus Base64URL zurück, sodass du sie lesen kannst – ganz ohne Secret. Verifizieren prüft die kryptografische Signatur, wofür das HMAC-Secret oder der öffentliche RSA-Schlüssel nötig ist. Ein Token kann sich perfekt decodieren lassen und trotzdem eine ungültige Signatur haben.

Kann ich ein JWT ohne geheimen Schlüssel decodieren?

Ja. Eine Standard-JWT-Payload ist nur codiert, nicht verschlüsselt, also brauchst du zum Lesen kein Secret. Das Secret ist nur nötig, um die Signatur zu prüfen oder neue Tokens zu erstellen. Wirklich verschlüsselte Tokens (JWE) sind ein anderes Format und lassen sich ohne den Schlüssel nicht lesen.

Warum zeigt mir mein Token im Decoder „ungültige Signatur“ an?

Fast immer, weil dem Decoder dein Signier-Secret fehlt – füge es in das Verifizierungsfeld ein. Andere Ursachen: Der Token wurde nach dem Signieren verändert, der falsche Algorithmus ist ausgewählt, oder es wurden versehentlich Leerzeichen mitkopiert. Die Payload decodiert sich so oder so problemlos.

Wie finde ich heraus, wann genau mein Token abläuft?

Decodiere den Token, lies den exp-Claim und rechne den Unix-Zeitstempel um – new Date(exp * 1000) in der Konsole liefert den exakten Ablaufzeitpunkt. Vergleiche mit der aktuellen Zeit, um die Restlaufzeit des Tokens zu sehen.

Tokens zu lesen ist eine alltägliche Debugging-Fähigkeit, keine Geheimwissenschaft. Jetzt, da du weißt, wie man JWT Token decodieren kann – die drei Teile, was exp, iat und sub bedeuten und warum echte Tokens Respekt verdienen –, wird die nächste mysteriöse eyJ...-Zeichenkette in Sekunden geknackt sein. Wenn sie auftaucht, decodiere sie kostenlos in deinem Browser mit Toolingas JWT-Decoder: einfügen, lesen, debuggen, fertig.