JWT Decoder

01

So funktioniert’s

1. 1

   Füg den Token ein, samt Bearer-Präfix

   Er wird beim Tippen dekodiert. Ist das Eingefügte kein JWT, sagt dir dieser JWT Decoder stattdessen, was es ist – ein JWE, eine opake Session-ID, ein API-Key oder ein Token, der auf dem Weg aus einem Log sein letztes Segment verloren hat.

2. 2

   Lies zuerst die Zeile zum Ablauf

   Vor vierzig Sekunden abgelaufen, wegen Clock Skew erst in zwei Minuten gültig oder gar kein exp-Claim. Das beantwortet die meisten Fragen, mit denen man zu einem JWT Debugger kommt – deshalb steht es ganz oben auf der Seite und nicht als Zahl, die du selbst umrechnen musst.

3. 3

   Dann lies die Befunde

   alg auf none, ein Header, der auf eine Key-URL zeigt, die ein Angreifer kontrollieren kann, eine Lebensdauer in Monaten oder eine E-Mail-Adresse im Payload, die alle lesen können, die den Token haben. Jeder Befund sagt, warum er zählt, statt ihn nur zu benennen.

02

Ein JWT ist signiert, nicht verschlüsselt

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

03

Warum der Token abgelehnt wird

04

Der Header ist eine Angriffsfläche

05

HS256 oder RS256

06

Was diese Seite nicht tut

07

Häufige Fragen

Speichert oder verschickt ihr meinen Token?

Nein. Der Decoder besteht aus ein paar Kilobyte JavaScript, die auf deinem Rechner laufen – es gibt keinen Serveraufruf, nichts wird geloggt, und es gibt kein Konto. Das zählt hier mehr als auf den meisten Seiten: Ein JWT aus einer aktiven Session ist bis zum Ablauf ein funktionierender Zugang. Einen davon in eine Website einzufügen ist also eher, als würdest du ein Passwort einfügen, als eine Config-Datei.

Warum prüft das Tool die Signatur nicht?

Weil du dafür den Key herausgeben müsstest. Bei HS256 ist das dein Signing Secret, und ein JWT Validator, der dich bittet, ein Signing Secret aus der Produktion in ein Textfeld im Internet einzufügen, verlangt etwas Schlimmeres als das Problem, das er löst. Bei RS256 bräuchtest du den Public Key des Ausstellers, und der verrät dir nur, dass der Token von dem signiert wurde, der den Private Key hat – das prüft dein eigenes Backend ohnehin bei jedem Request. Alles, was diese Seite anzeigt, lässt sich ohne beides feststellen.

Ist der Payload verschlüsselt?

Nein, und das ist das häufigste Missverständnis über JWTs überhaupt. Der Payload ist base64url, keine Verschlüsselung – eine Signatur verhindert, dass er verändert wird, nicht, dass er gelesen wird. Alle, die den Token haben, sehen jeden Claim: deine eigenen Kund:innen, jeder Proxy auf dem Weg und alles, was einen Authorization-Header loggt. Deshalb listet dieser JWT Decoder jeden Claim auf, dessen Name nach personenbezogenen Daten aussieht – denn diese Daten sind für alle, die der Token erreicht, praktisch öffentlich.

Mein Token ist gültig, aber die API lehnt ihn ab. Was jetzt?

In der Reihenfolge, in der es tatsächlich passiert: Der Token ist zwischen Ausstellung und Nutzung abgelaufen; nbf liegt in der Zukunft, weil die Uhr des ausstellenden Servers der prüfenden Seite voraus ist; der aud-Claim nennt einen anderen Service; iss passt nicht zu dem, was die prüfende Seite erwartet; oder es ist ein ID-Token, der dort ankommt, wo ein Access-Token erwartet wird. Das Panel zeigt alle fünf – deshalb taugt es als JWT Debugger mehr als ein reines Dekodieren.

Was bedeutet alg: none?

Dass der Token nicht signiert ist. Eine Library, die den Algorithmus aus dem Token liest, statt den erwarteten festzulegen, akzeptiert bereitwillig einen Payload, den jemand bearbeitet hat – der Angriff aus CVE-2015-9235, der immer noch in echtem Code ausgeliefert wird. Deshalb wird er als Gefahr markiert. Wenn du ihn bei einem Token aus einem Produktivsystem siehst, ist nicht der Token das Problem.

Warum warnt es vor jku und x5u im Header?

Diese Header-Parameter sagen der prüfenden Seite, wo sie den Key abholen soll. Folgt sie der URL ohne Allowlist, kontrolliert, wer den Token kontrolliert, auch den Key – und damit die Signatur. Ein jwk im Header ist dasselbe Problem in einem kürzeren Loop: Der Token liefert den Key mit, mit dem der Token geprüft wird.

Was ist der Unterschied zwischen einem ID-Token und einem Access-Token?

Ein ID-Token beschreibt, wer die Person ist, und ist für deine Anwendung gedacht. Ein Access-Token autorisiert einen Aufruf und ist für eine API gedacht. Beide sehen gleich aus, deshalb ist es ein so häufiger Bug, den falschen zu schicken – der token_use-Claim von Cognito existiert genau dafür, sie zu unterscheiden, und ein JWT Validator auf API-Seite sollte ihn prüfen.

Kann es mir sagen, welcher Anbieter den Token ausgestellt hat?

Ja, über den iss-Claim. Auth0, AWS Cognito, Firebase, Keycloak, Okta, Supabase, Microsoft Entra ID, Clerk, Stytch und WorkOS werden an ihren Issuer-URLs erkannt. Eine Kleinigkeit, aber nützlich, wenn ein Token aus einem System kommt, das du nicht selbst eingerichtet hast.

Funktioniert es als JWT Token Decoder für Tokens aus einem Header oder einer Logzeile?

Ja. Ein vorangestelltes Bearer wird automatisch entfernt, Leerzeichen drumherum werden ignoriert. Als JWT Token Decoder verarbeitet es außerdem base64url korrekt – die Bindestriche und Unterstriche, die in den meisten echten Signaturen vorkommen und an denen Decoder auf Basis von reinem Base64 stillschweigend scheitern.

Warum warnt es vor der Token-Größe?

Weil Browser ein einzelnes Cookie auf etwa 4 KB begrenzen, und mehrere Proxys und Server begrenzen Request-Header standardmäßig ebenfalls. Ein Token, der über diese Grenze wächst, scheitert auf eine Art, die wie ein Auth-Bug aussieht und keiner ist. Große Arrays mit Rollen oder Berechtigungen sind fast immer die Ursache.

Warum warnt es vor langen Lebensdauern?

Ein Bearer-Token ist gültig, bis er abläuft, und dazwischen fragt nichts beim Aussteller nach. Ein geleakter Token mit dreißig Tagen Lebensdauer ist also ein Problem für dreißig Tage, solange du keine Denylist pflegst. Kurze Access-Tokens plus ein Refresh-Token gibt es, um dieses Zeitfenster klein zu halten.

Was, wenn ich etwas einfüge, das kein JWT ist?

Dann erfährst du, was es ist. Fünf Segmente bedeuten ein JWE – verschlüsselt und ohne Key nicht lesbar. Ein einzelner opaker String ist eine Session-ID, kein Token mit Inhalt. Zwei Segmente heißen meist, dass die Signatur beim Kopieren abgeschnitten wurde. „Ungültiger Token“ würde dich auf die Suche nach einem Tippfehler schicken, den es nicht gibt.

Gibt es einen JWT Decoder für abgelaufene Tokens?

Diesen hier. Der Ablauf ist ein Claim im Payload, keine Eigenschaft der Kodierung, ein abgelaufener Token lässt sich also genauso dekodieren wie ein gültiger – der Unterschied ist nur, dass die prüfende Seite ihn ablehnt. Einen abgelaufenen Token lesen zu können ist meist genau der Grund, einen Decoder zu öffnen.

Warum ist das kostenlos, und was ist Tekk?

Mit Tekk wird dein Produkt zu Software, die sich selbst verbessert: 16 Loops beobachten deine Codebase und bringen dir Proposals, die du mit Greenlight freigibst oder ablehnst, und dein Coding-Agent baut das Ergebnis. Diese Seite kostet im Betrieb nichts, weil nichts auf unseren Servern läuft – deshalb gibt es keine Anmeldepflicht, kein Limit und keinen Upsell im Tool.