JWT erklärt: Struktur, Claims und wie man eines dekodiert

Wer mit einer modernen Web-API gearbeitet hat, ist JWTs begegnet — jenen langen Kauderwelsch-Zeichenketten mit zwei Punkten, die in Login-Antworten und Authorization-Headern auftauchen. Sie wirken undurchsichtig, sind aber erstaunlich lesbar, sobald man die Struktur kennt. Dieser Ratgeber erklärt, was ein JSON Web Token ist, was drinsteckt, wie die Signatur funktioniert und welche Sicherheitsfehler zu vermeiden sind.

Wofür ein JWT da ist

Ein JSON Web Token (JWT) ist eine kompakte, in sich geschlossene Art, eine Reihe von Claims zu transportieren — Aussagen wie „das ist Nutzer 42 und er hat sich um 10:05 angemeldet“. Sein Hauptzweck ist die Authentifizierung: Nach dem Login stellt ein Server ein JWT aus, deine App sendet es bei jeder Anfrage zurück, und der Server vertraut ihm, statt dich jedes Mal in einem Session-Speicher nachzuschlagen. Weil das Token die Information selbst trägt, heißt es zustandslos (stateless).

Die drei Teile

Jedes JWT besteht aus drei durch Punkte verbundenen Base64URL-kodierten Abschnitten: header.payload.signature.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.3x9kQ...
└──── header ────┘ └── payload ──┘ └ signature ┘

1. Header

Metadaten über das Token — der Signaturalgorithmus (alg, z. B. HS256) und der Typ (typ: JWT). Dekodiert ist es nur kleines JSON:

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

2. Payload

Die Claims — die eigentlichen Daten. Manche Namen sind standardisiert (registrierte Claims genannt):

• sub — Subjekt, meist die Nutzer-ID.
• iss — Aussteller (issuer), wer das Token erstellt hat.
• aud — Zielgruppe (audience), für wen es bestimmt ist.
• exp — Ablaufzeit (ein Unix-Zeitstempel).
• iat — Ausstellungszeit (ein Unix-Zeitstempel).

Diese exp- und iat-Werte sind Sekunden seit 1970 — musst du sie als echte Daten lesen, macht ein Zeitstempel-Konverter daraus menschenlesbare Zeiten.

3. Signatur

Die Signatur ist das, was das Token vertrauenswürdig macht. Der Aussteller nimmt Header und Payload und erzeugt mit einem geheimen Schlüssel eine kryptografische Signatur. Jeder mit dem Schlüssel kann prüfen, dass Header und Payload nicht verändert wurden — ändere ein einziges Zeichen im Payload und die Signatur passt nicht mehr.

Das Wichtigste zu verstehen

Ein JWT ist signiert, nicht verschlüsselt. Header und Payload sind nur Base64URL-kodiert, was bedeutet, dass jeder sie dekodieren und lesen kann — kein Schlüssel nötig. Die Signatur verhindert Manipulation, nicht Lesen.

Die praktische Folge: Stecke niemals Geheimnisse in ein JWT-Payload. Keine Passwörter, keine Kreditkartennummern, keine privaten Daten — nimm an, das Payload sei öffentlich. Du kannst das selbst bestätigen, indem du ein beliebiges Token in unseren JWT-Decoder einfügst, der Header und Claims sofort liest, komplett in deinem Browser (das Token verlässt dein Gerät nie). Darunter ist es nur Base64-Dekodierung — der Decoder spart dir nur die Schritte.

Verifizieren vs. Dekodieren

Das sind zwei verschiedene Handlungen, und sie zu verwechseln ist ein echter Sicherheitsfehler. Dekodieren liest das Payload — jeder kann es und es beweist nichts. Verifizieren prüft die Signatur mit dem Schlüssel und bestätigt, dass das Token echt und unverändert ist. Ein Server muss jedes Token verifizieren, bevor er ihm vertraut; Dekodieren allein ist keine Authentifizierung.

Häufige Fallstricke

• Einem unverifizierten Token vertrauen — prüfe die Signatur immer serverseitig, bevor du auf die Claims hin handelst.
• Ablauf ignorieren — beachte exp; ein abgelaufenes Token sollte abgelehnt werden.
• Sensible Daten im Payload speichern — es ist für jeden lesbar.
• Die `alg: none`-Falle — manche Bibliotheken akzeptierten einst Tokens, die „keine Signatur“ behaupteten. Lehne sie ab und lege den erwarteten Algorithmus fest.

Verstehe das, und JWTs werden von einschüchternden Zeichenketten zu einem simplen, transparenten Format: lesbare Claims, geschützt durch eine Signatur, die du verifizieren musst, bevor du vertraust.