Wie Sie JWT-Token dekodieren und prüfen
JSON Web Tokens (JWTs) sind die häufigste Methode, Authentifizierung in modernen Webanwendungen zu handhaben. Wenn bei der Authentifizierung etwas schiefgeht — eine Nutzerin wird unerwartet abgemeldet, Berechtigungen sind falsch oder eine API liefert 401 — ist das Decodieren des JWT meist der erste Debugging-Schritt.
Was in einem JWT steckt
Ein JWT besteht aus drei Teilen, getrennt durch Punkte:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8UHeader — enthält den Algorithmus (HS256, RS256 usw.) und den Token-Typ.
{"alg": "HS256", "typ": "JWT"}Payload — enthält Claims (Aussagen) zum Nutzer und zum Token.
{"sub": "1234567890", "name": "Alice", "exp": 1700000000}Signatur — eine kryptografische Prüfsumme, die bestätigt, dass das Token nicht manipuliert wurde. Sie können sie ohne den Signaturschlüssel nicht lesen.
Übliche JWT-Claims
| Claim | Vollständiger Name | Inhalt |
|---|---|---|
sub |
Subject | Nutzer-ID oder Identifikator |
exp |
Expiration | Unix-Zeitstempel, wann das Token abläuft |
iat |
Issued At | Unix-Zeitstempel der Erstellung |
iss |
Issuer | Wer das Token erstellt hat (Ihr Auth-Server) |
aud |
Audience | Für wen das Token bestimmt ist |
nbf |
Not Before | Token ist vor diesem Zeitpunkt nicht gültig |
jti |
JWT ID | Eindeutiger Identifikator des Tokens |
So decodieren Sie ein JWT
- Token einfügen — geben Sie das vollständige JWT (Format header.payload.signature) in den Decoder ein.
- Decodierte Abschnitte ansehen — das Tool zeigt Header (Algorithmus), Payload (Claims) und Signatur als formatiertes JSON.
- Claims prüfen — untersuchen Sie Ablaufzeit, Issuer, Subject und alle benutzerdefinierten Claims.
Debugging mit JWTs
Token abgelaufen? Prüfen Sie den exp-Claim. Wandeln Sie den Unix-Zeitstempel in ein lesbares Datum um. Liegt er in der Vergangenheit, ist das Token abgelaufen und muss erneuert werden.
Falsche Berechtigungen? Suchen Sie im Payload nach Rollen- oder Scope-Claims. Diese variieren je nach Implementierung, sehen aber oft aus wie "role": "admin" oder "scope": "read write".
Probleme mit der Nutzeridentität? Der sub-Claim identifiziert den Nutzer. Prüfen Sie, ob er der erwarteten Nutzer-ID entspricht.
Token wird abgelehnt? Prüfen Sie den aud-Claim (Audience). Wenn die API einen bestimmten Audience-Wert erwartet und das Token einen anderen hat, wird es zurückgewiesen.
Wichtige Sicherheitshinweise
- JWTs sind nicht verschlüsselt — jeder kann das Payload decodieren. Speichern Sie keine Passwörter, API-Schlüssel oder andere Geheimnisse in einem JWT.
- Signaturen immer auf dem Server prüfen — ein Decoder zeigt Ihnen, was das Token behauptet, aber nur die Signaturprüfung beweist, dass es nicht manipuliert wurde.
- Ablauf prüfen — abgelaufene Tokens müssen immer abgelehnt werden. Wenn Ihre Anwendung abgelaufene Tokens akzeptiert, ist das ein Sicherheitsfehler.
Häufig gestellte Fragen
Kann ich eine JWT-Signatur mit einem Decoder überprüfen?
Nein. Die Signaturprüfung erfordert das Signaturgeheimnis oder den öffentlichen Schlüssel, die auf Ihrem Server liegen. Ein Decoder zeigt Ihnen, was im Token steckt, doch die kryptografische Prüfung muss in Ihrem Backend erfolgen. Vertrauen Sie in Produktion nie einem unverifizierten JWT.
Ist es sicher, ein JWT in ein Online-Tool einzufügen?
Ja, wenn das Tool im Browser läuft. Browserbasierte Decoder verarbeiten das Token lokal — nichts wird an einen Server gesendet. Vermeiden Sie Tools, die Netzwerkanfragen mit Ihrem Token machen.
Was ist der exp-Claim?
Der exp-Claim (Expiration) ist ein Unix-Timestamp, der angibt, wann das Token abläuft. Nach diesem Zeitpunkt sollte es abgelehnt werden. Prüfen Sie diesen Claim immer beim Debuggen von Authentifizierungsproblemen.
Können JWTs verschlüsselt werden?
Standard-JWTs (JWS) sind signiert, aber nicht verschlüsselt — jeder kann den Payload dekodieren. JWE-Token (JSON Web Encryption) sind verschlüsselt, aber weniger verbreitet. Geben Sie nie sensible Daten (Passwörter, Geheimnisse) in einen Standard-JWT-Payload.