JWT-Token dekodieren mit Base64 — Payload und Header lesen
JSON Web Tokens (JWT) sind der De-facto-Standard für Authentifizierung in modernen Webanwendungen. Doch was steckt eigentlich in einem JWT? Hinter der scheinbar kryptischen Zeichenkette aus drei Punkten verbirgt sich Base64URL-kodierter JSON — lesbar für jeden mit dem richtigen Tool. Unser kostenloser Base64-Dekoder ermöglicht es, JWT-Tokens sofort zu entschlüsseln und den Inhalt zu lesen. Unverzichtbar für Entwickler beim Debuggen von Authentifizierungsproblemen.
Aufbau eines JWT: Header, Payload und Signatur
Ein JWT besteht aus drei durch Punkte getrennten Base64URL-kodierten Teilen. Der Header enthält den Algorithmus und den Token-Typ, zum Beispiel {"alg":"HS256","typ":"JWT"}. Der Payload enthält die Claims — Behauptungen über den Nutzer und Token, wie {"sub":"1234567890","name":"Max Mustermann","iat":1516239022,"exp":1716239022}. Die Signatur ist der kryptographische Nachweis, dass der Token nicht manipuliert wurde — sie kann nicht mit Base64 allein überprüft werden. Für Debugging-Zwecke reicht das Dekodieren von Header und Payload, um zu verstehen, welche Daten der Token enthält.
Häufige JWT-Claims und ihre Bedeutung
JWT-Payloads enthalten standardisierte und benutzerdefinierte Claims. Standardisierte Claims (JWT-Spezifikation RFC 7519): iss (Issuer: wer hat den Token ausgestellt?), sub (Subject: für wen gilt der Token?), aud (Audience: für welche Anwendung?), exp (Expiration Time: wann läuft der Token ab? — Unix-Timestamp), iat (Issued At: wann wurde der Token ausgestellt?), nbf (Not Before: ab wann ist der Token gültig?). Benutzerdefinierte Claims ergänzen diese um anwendungsspezifische Daten wie Benutzerrollen, E-Mail-Adressen oder Berechtigungen. Unser Tool dekodiert den Base64URL-Payload und zeigt das JSON verständlich formatiert an.
JWT debuggen: Typische Probleme finden
Das Dekodieren eines JWT hilft bei der Diagnose häufiger Authentifizierungsprobleme. Problem 1: Token abgelaufen. Dekodieren Sie den Payload und prüfen Sie den exp-Wert (Unix-Timestamp) — ist er in der Vergangenheit, ist der Token ungültig. Problem 2: Falsche Audience. Der aud-Claim muss zur Anwendung passen. Problem 3: Fehlende Berechtigungen. Prüfen Sie, welche Rollen oder Scopes im Token enthalten sind. Problem 4: Falscher Algorithmus. Der alg-Wert im Header zeigt, welcher Signing-Algorithmus verwendet wird. Unser Base64-Tool macht es einfach, diese Informationen schnell aus einem JWT zu extrahieren, ohne Code schreiben zu müssen.
Sicherheitshinweise beim Umgang mit JWTs
Wichtig zu verstehen: JWTs sind base64-kodiert, nicht verschlüsselt (es sei denn, Sie verwenden JWE — JSON Web Encryption). Der Payload eines Standard-JWT kann von jedem gelesen werden, der den Token hat. Speichern Sie daher keine sensitiven Daten wie Passwörter oder Kreditkartennummern im JWT-Payload. Validieren Sie immer die Signatur serverseitig — das Dekodieren allein beweist nicht, dass der Token authentisch ist. Prüfen Sie immer den exp-Claim, um abgelaufene Tokens abzulehnen. Unser Base64-Decoder läuft vollständig im Browser — Ihre Tokens werden nicht an Server gesendet und verlassen Ihr Gerät nicht.
Häufig gestellte Fragen
- Kann ich ein JWT mit Base64 validieren?
- Nein, das Dekodieren eines JWT mit Base64 liest nur den Inhalt. Die Validierung der Signatur erfordert den geheimen Schlüssel oder das öffentliche Zertifikat. Für Debugging und Inspektion reicht das Dekodieren, aber nie für Sicherheitsentscheidungen verwenden.
- Warum endet ein JWT oft mit == oder =?
- Das = Zeichen ist das Base64-Padding. Es wird verwendet, wenn die Datenlänge kein Vielfaches von 3 Bytes ist. Base64URL für JWTs lässt das Padding oft weg — das ist der Grund, warum JWT-Segmente manchmal kein = haben, obwohl die Dekodierung identisch funktioniert.
- Wie lange sollte ein JWT gültig sein?
- Das hängt vom Anwendungsfall ab. Kurzlebige Access Tokens (15 Minuten bis 1 Stunde) sind für APIs empfohlen. Refresh Tokens können länger gültig sein (Tage bis Wochen). Je länger ein Token gültig ist, desto größer ist das Risiko bei Kompromittierung. Der exp-Claim im Payload zeigt die Ablaufzeit als Unix-Timestamp.