JWT-Decoder

Die Claims darin verstehen

Ist ein Token einmal dekodiert, besteht die Payload größtenteils aus einer Handvoll kurzer, standardisierter Felder namens Claims. Die, denen Sie ständig begegnen: iss nennt den Aussteller, der das Token erzeugt hat, sub identifiziert den Nutzer oder das Subjekt, um das es geht, aud nennt die Zielgruppe — die API, für die es gedacht ist —, während iat festhält, wann es ausgestellt wurde, und exp, wann es aufhört, gültig zu sein. Alles andere darin ist individuell: Rollen, E-Mail-Adressen, Feature-Flags, was auch immer das ausstellende System hineinpacken wollte. Die Zeit-Claims bringen Menschen ins Stolpern, weil es schlichte Unix-Timestamps sind, Sekunden seit 1970 — eine Zahl wie 1784528768 statt eines lesbaren Datums —, sodass sich die gesamte Lebensdauer des Tokens in zwei unscheinbaren Ganzzahlen verbirgt.

Ein abgelehntes Token debuggen

Antwortet eine API mit 401 und Sie sind sicher, dass das Token stimmt, arbeiten Sie eine kurze Liste ab. Zuerst: Haben Sie es aus einem Authorization-Header kopiert, entfernen Sie das Wort Bearer und das Leerzeichen davor — mit diesen dran ist es kein gültiges JWT und lässt sich nicht einmal dekodieren. Als Nächstes lesen Sie exp und prüfen, ob es tatsächlich in der Zukunft liegt: Fügen Sie die Zahl in den Unix-Timestamp-Konverter ein, und Sie sehen den Ablauf als echtes Datum — oft entlarvt das ein Token, das schon vor Stunden gestorben ist. Vergleichen Sie dann aud und iss mit der API, die Sie aufrufen — ein Token, das für die Staging-Umgebung geprägt wurde, wird von der Produktion routinemäßig und zu Recht abgelehnt. Und denken Sie daran: Eine Minute Uhrenabweichung zwischen Servern genügt, damit ein gerade erst ausgestelltes Token noch-nicht-gültig aussieht.

Tokens, die dieses Tool nicht öffnen kann

Nicht alles, was eine API bewacht, ist ein lesbares JWT. Ein Token mit fünf durch Punkte getrennten Teilen statt drei ist ein JWE — wirklich verschlüsselt, nicht nur kodiert —, und ohne den Schlüssel kommt hier wie überall sonst nichts Lesbares heraus. Und viele Session-Tokens sind schlicht undurchsichtige Zufallszeichenketten, die von Anfang an nie JWTs waren; beginnt es nicht mit so etwas wie eyJ, gibt es wahrscheinlich nichts zu dekodieren. Bei den Tokens, die sich öffnen lassen, hilft es, sich zu vergegenwärtigen, was man da vor sich hat: drei mit Punkten verklebte Blöcke Base64URL-Text. Das Base64-Tool dekodiert jeden einzelnen Block für sich, was eine schöne Möglichkeit ist, mit eigenen Augen zu sehen, dass die lesbaren Teile eines JWT von Anfang an nie geheim waren.

Was das Dekodieren eines JWT verrät — und was nicht

Header und Payload eines JWT sind lediglich Base64URL-kodiertes JSON — jeder kann sie dekodieren und lesen, ohne dass ein Geheimnis nötig wäre, genau das tut dieses Tool. Was es nicht kann: die Signatur verifizieren — dafür braucht es das Geheimnis oder den öffentlichen Schlüssel des Ausstellers, und das gibt man bewusst nicht in eine beliebige Website ein.