JWT dekodieren
Ein JWT besteht aus drei base64url-Strings, die durch Punkte verbunden sind: Header, Payload und Signatur. Zum Dekodieren teilen Sie an den Punkten und dekodieren die ersten beiden Teile aus base64url; jeder ist ein JSON-Objekt. Dafür ist kein Schlüssel nötig, denn ein signiertes JWT ist nicht verschlüsselt. Das Dekodieren beweist nichts: Nur die Prüfung der Signatur mit dem Secret oder dem öffentlichen Schlüssel des Ausstellers sowie der Claims exp, nbf, iss und aud zeigt, dass das Token echt und noch gültig ist.

Wie ist ein JWT aufgebaut?
Nehmen wir das öffentliche Beispiel-Token aus der JWT-Dokumentation:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 .eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Der erste Teil dekodiert zu {"alg":"HS256","typ":"JWT"}: Das Token ist mit HMAC-SHA256 signiert. Der zweite ergibt {"sub":"1234567890","name":"John Doe","iat":1516239022}. Der dritte ist die Signatur, rohe Bytes in base64url, die nur mit dem Schlüssel Sinn ergeben.
Welche Claims sind üblich?
| Claim | Bedeutung |
|---|---|
| sub | Subjekt: worum es im Token geht, meist eine Benutzer-ID |
| iss | Aussteller: wer das Token erstellt hat |
| aud | Zielgruppe: welche API es akzeptieren soll |
| iat | Ausgestellt um, Unix-Sekunden (1516239022 = 18.01.2018 01:30:22 UTC) |
| nbf | Nicht gültig vor, Unix-Sekunden |
| exp | Läuft ab um, Unix-Sekunden |
| scope / roles | Berechtigungen (Name je nach Anbieter) |
Wie debuggt man einen 401-Fehler?
Ein API-Aufruf, der gestern funktionierte, liefert jetzt 401. Dekodieren Sie das Token aus dem Authorization-Header und prüfen Sie der Reihe nach:
- exp: Liegt es in der Vergangenheit? Die meisten Zugriffstokens leben 5 bis 60 Minuten; das ist die häufigste Ursache.
- aud: Nennt es die aufgerufene API?
- iss: Stammt es aus der richtigen Umgebung? Ein Staging-Token scheitert in Produktion.
- scope oder roles: Ist die nötige Berechtigung vorhanden?
- Uhrzeitabweichung: Liegt iat oder nbf einige Sekunden in der Zukunft, gehen die Uhren auseinander.
Sieht alles richtig aus, liegt es wahrscheinlich an der Signatur, etwa an einem rotierten Signaturschlüssel.
Welche Sicherheitsfehler sollten Sie vermeiden?
- Einem dekodierten Payload vertrauen. Jeder kann ein Token mit "role": "admin" erstellen; nur eine geprüfte Signatur macht die Claims vertrauenswürdig.
- alg "none" akzeptieren oder das Token den Algorithmus wählen lassen. Legen Sie den erwarteten Algorithmus auf dem Server fest.
- Geheimnisse in den Payload schreiben. Ein signiertes JWT kann jeder lesen, der es besitzt.
- Ein aktives Token in ein Online-Tool einfügen, das es an einen Server schickt. Der JWT-Decoder dieser Website dekodiert im Browser, ohne etwas zu senden.
Wie lässt sich ein JWT dekodieren? Drei Wege
- Im Browser: Fügen Sie das Token in den JWT-Decoder ein. Er zeigt Header und Payload als JSON, wandelt iat, nbf und exp in Datumswerte um und zeigt, ob das Token abgelaufen ist. Nichts wird gesendet.
- Im Terminal: Nehmen Sie den mittleren Teil, wandeln Sie base64url in base64 um (- durch + und _ durch / ersetzen, =-Auffüllung ergänzen), führen Sie
base64 -daus und leiten Sie das Ergebnis anjqweiter. - Im Code: Die meisten JWT-Bibliotheken haben eine Dekodierfunktion ohne Prüfung, nur zum Debuggen. In Produktion rufen Sie die Verifizierungsfunktion mit Schlüssel, Algorithmus, Aussteller und Zielgruppe auf.
FAQ
Brauche ich das Secret, um ein JWT zu dekodieren?
Nein. Header und Payload sind nur base64url-kodiert. Secret oder öffentlicher Schlüssel dienen zur Prüfung der Signatur, nicht zum Lesen.
Warum hat mein JWT fünf Teile?
Das ist ein verschlüsseltes Token (JWE): Der Inhalt ist nur mit dem Entschlüsselungsschlüssel lesbar.
Woran erkenne ich, ob ein JWT abgelaufen ist?
Vergleichen Sie den Claim exp (Unix-Sekunden) mit der aktuellen Zeit. Der JWT-Decoder dieser Website zeigt ihn als Datum und markiert abgelaufene Tokens.
Aktualisiert: November 2026. Die Dateien werden in Ihrem Browser verarbeitet und nicht hochgeladen.