JWT-Decoder

Was ist ein JWT Decoder?

Ein JWT Decoder zerlegt einen JSON Web Token in seine drei Teile – Header, Payload und Signature – und Base64URL-dekodiert die ersten beiden, sodass du sie als JSON lesen kannst. Beim Debuggen von Login-Flows, Authorization, Session-Claims oder abgelaufenen Tokens gehört das zum täglichen Werkzeug.

Einen JWT zu dekodieren heißt *nicht*, ihm zu vertrauen. Header und Payload sind absichtlich lesbar – sie sind nur Base64URL-codiert, nicht verschlüsselt. Erst die Verifikation prüft, ob der Token wirklich vom erwarteten Aussteller signiert wurde und unterwegs nicht verändert wurde.

Ein JWT sieht aus wie header.payload.signature. Jeder Teil ist Base64URL-codiert und durch Punkte getrennt. Der Header sagt, welcher Signaturalgorithmus verwendet wurde, der Payload trägt die Claims (wer der Nutzer ist, wann der Token abläuft, was er darf), und die Signature erlaubt dem Server zu prüfen, dass am Token nichts verändert wurde.

Was du beim Dekodieren von JWTs lernst

• Ein JWT besteht aus drei Base64URL-codierten Teilen, getrennt durch Punkte: header.payload.signature.
• Übliche Claims wie sub, role, iat, nbf und exp beschreiben Identität, Berechtigungen, Ausstellungszeitpunkt und Ablaufzeit.
• Den dekodierten Payload kann jeder verändern – nur die Signature lässt den Server eine Manipulation erkennen.

Schritt für Schritt: einen JWT dekodieren

1. 1

   Den vollständigen Token einfügen

   Füge den JWT in das Eingabefeld ein. Er sollte aussehen wie xxxx.yyyy.zzzz – drei Base64URL-codierte Teile, verbunden durch Punkte.

2. 2

   Header lesen

   Der Header verrät dir den Signaturalgorithmus (alg) und den Token-Typ. Achtung bei "alg": "none" – das bedeutet, der Token ist unsigniert und nicht vertrauenswürdig.

3. 3

   Claims im Payload lesen

   Der Payload ist das JSON mit allen Claims. Schau nach sub (User-ID), exp (Ablauf), iat (ausgestellt am) und nach eigenen Claims deiner Anwendung wie role oder tenant.

4. 4

   Ablaufzeit prüfen

   Wandle den Unix-Timestamp aus exp in ein Datum um – liegt es in der Vergangenheit, ist der Token abgelaufen und jede ordentliche API wird ihn ablehnen.

5. 5

   Signature verifizieren (optional)

   Wenn du das Secret oder den Public Key hast, gib es bzw. ihn im Verifier an, um die Signature zu prüfen. Den Inhalten kannst du erst trauen, wenn die Signatur stimmt.

Standard-Claims im JWT

Das sind die in der JWT-Spezifikation (RFC 7519) registrierten Claims. Jede Anwendung darf zusätzlich eigene Custom Claims definieren.

JWT-Beispiele zum Ausprobieren

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

{  "sub": "user_123",  "role": "student",  "exp": 1710000000}

{  "exp": 1710000000}

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

Typische Fehler im Umgang mit JWTs

• Passwörter, Secrets oder sensible personenbezogene Daten in den Payload schreiben. JWTs sind lesbar, nicht verschlüsselt.
• Einen Token dekodieren und ihn dann für gültig halten, ohne die Signatur zu prüfen.
• Base64URL-Lesbarkeit mit Verschlüsselung verwechseln – JWT-Payloads sind absichtlich offen lesbar.

FAQ zu JWT