Inhaltsverzeichnis
JWT-Anatomie: Header, Payload, Signatur
Ein JSON Web Token sieht so aus:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Drei Abschnitte, getrennt durch Punkte. Jeder Abschnitt ist Base64URL-kodiertes JSON:
| Abschnitt | Enthalt | Beispiel |
|---|---|---|
| Header (rot) | Token-Typ + Signieralgorithmus | {"alg":"HS256","typ":"JWT"} |
| Payload (lila) | Claims — Benutzerdaten + Metadaten | {"sub":"123","name":"John","iat":1516239022} |
| Signatur (blau) | Kryptografische Signatur von Header+Payload | SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c |
Die Signatur wird berechnet durch: HMACSHA256(base64url(header) + "." + base64url(payload), secret). Das bedeutet, jeder kann Header und Payload lesen — sie sind nur Base64, nicht verschl黶selt. Aber sie konnen sie nicht andern, ohne die Signatur ungultig zu machen (es sei denn, sie kennen das Geheimnis).
So Dekodieren Sie Einen JWT in Sekunden
Sie haben drei Moglichkeiten:
1. Ein JWT-Decoder-Tool verwenden (am schnellsten)
F黦en Sie Ihr Token in den iluv.tools JWT Decoder ein. Er dekodiert sofort Header und Payload, zeigt die Ablaufzeit in einem lesbaren Format an und hebt hervor, ob das Token abgelaufen ist. Keine Daten verlassen Ihren Browser.
2. Browser-Konsole
// JWT-Payload dekodieren
const token = "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.xxx";
const payload = JSON.parse(atob(token.split('.')[1]));
console.log(payload);
3. Kommandozeile
echo "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.xxx" | cut -d'.' -f2 | base64 -d 2>/dev/null | python -m json.tool
Was der Payload Tatsachlich Enthalt
JWT-Claims sind die Schlussel-Wert-Paare im Payload. Sie kommen in drei Varianten:
| Claim | Bedeutung | Beispiel |
|---|---|---|
iss (Issuer) | Wer das Token erstellt hat | "auth.mysite.com" |
sub (Subject) | Uber wen das Token ist (Benutzer-ID) | "user_12345" |
aud (Audience) | Fur wen das Token bestimmt ist | "api.mysite.com" |
exp (Expiration) | Unix-Zeitstempel, wann das Token ablauft | 1716931200 |
iat (Issued At) | Unix-Zeitstempel, wann das Token erstellt wurde | 1716927600 |
nbf (Not Before) | Token ist vor diesem Zeitstempel ungultig | 1716927600 |
jti (JWT ID) | Eindeutige Kennung fur dieses Token | "a1b2c3d4" |
Der exp-Claim ist der wichtigste fur das Debugging. Wenn Ihre API 401 Unauthorized zur黦ibt, dekodieren Sie zuerst den JWT. Prufen Sie exp — wandeln Sie den Unix-Zeitstempel in ein lesbares Datum um. Liegt er in der Vergangenheit? Token abgelaufen. Ist er null oder fehlt? Das Token lauft vielleicht nie ab (haufig bei falsch konfigurierten Auth-Servern).
Haufige JWT-Probleme und Wie Man Sie Behebt
1. "JWT abgelaufen" / 401-Fehler
Dekodieren Sie das Token. Prufen Sie exp. Wenn es in der Vergangenheit liegt: Das Token ist abgelaufen und der Client muss es erneuern. Die meisten Auth-Server setzen exp auf 15-60 Minuten nach iat. Wenn exp 50 Jahre in der Zukunft liegt: Der Auth-Server ist falsch konfiguriert (oder dies ist ein Test-Token).
2. "Ungultige Signatur"-Fehler
Das Token wurde nach dem Signieren verandert, ODER der Server verwendet ein anderes Geheimnis als das, mit dem es signiert wurde. Haufige Ursachen: Unterschiede in Umgebungsvariablen (Dev-Secret vs. Prod-Secret), Secret-Rotation oder der Client hat die Token-Zeichenfolge versehentlich getruncated/verandert.
3. "Algorithmus nicht unterstutzt"
Prufen Sie das alg-Feld des Headers. Wenn es "none" sagt, ist das Token nicht signiert — weisen Sie es zuruck. Der "None-Algorithmus"-Angriff ist klassisch: Einige JWT-Bibliotheken akzeptierten Tokens mit {"alg":"none"} als gultig, ohne die Signatur zu prufen. Uberprufen Sie immer alg gegen eine Whitelist.
4. Audience-Konflikt
Prufen Sie aud im Payload. Wenn Ihre API "api.mysite.com" erwartet, das Token aber "other-service.com" angibt, wurde das Token fur einen anderen Dienst ausgestellt. Dies passiert in Microservice-Setups, wenn Tokens an den falschen Dienst weitergeleitet werden.
JWT-Sicherheit: Was Schiefgehen Kann
- Token-Leak — JWTs sind Bearer-Tokens. Jeder, der das Token hat, kann es verwenden. Speichern Sie sie in httpOnly-Cookies, nicht im localStorage (XSS kann localStorage lesen). Setzen Sie kurze Ablaufzeiten und verwenden Sie Refresh-Tokens fur langere Gultigkeit.
- Kein Widerrufsmechanismus — JWTs sind von Natur aus zustandslos. Einmal ausgestellt, sind sie gultig, bis sie ablaufen. Es gibt kein eingebautes "Ausloggen" oder "Token widerrufen". Losungen: Token-Blacklists (zustandsbehaftet, widerspricht dem Zweck), kurzlebige Access-Tokens (5-15 Min.) + widerrufbare Refresh-Tokens.
- Schwache Signiergeheimnisse — Bei Verwendung von HS256 (HMAC) muss das Geheimnis ein kryptografisch zufalliger String von mindestens 256 Bit (32 Bytes) sein. "meingeheimnis" oder "passwort123" kann in Minuten erraten werden.
- None-Algorithmus-Angriff — Validieren Sie immer
alggegen eine Erlaubnisliste. Akzeptieren Sie niemals"none". - Key-Confusion-Angriff — Wenn Ihr Server sowohl HS256 (symmetrisch) als auch RS256 (asymmetrisch) akzeptiert, kann ein Angreifer den RS256-offentlichen Schlussel als HS256-Geheimnis verwenden, um Tokens zu falschen. Gegenma?nahme: Verwenden Sie separate Validierungspfade oder akzeptieren Sie nur einen Algorithmus.