JWT-Decoder

So dekodieren Sie ein JWT

1. Fügen Sie das Token in das Feld „JSON Web Token“ ein. Auch ein kompletter Authorization: Bearer …-Wert funktioniert: Das Präfix Bearer und eventuelle Zeilenumbrüche werden entfernt.
2. Das Token wird schon beim Tippen dekodiert (oder per Klick auf „Dekodieren“). „Header“ und „Payload“ erscheinen als formatiertes JSON, jeweils mit eigener „Kopieren“-Schaltfläche.
3. Lesen Sie die Tabelle „Zeit-Claims“: exp, nbf und iat werden mit Rohwert, Datum in Ihrer Zeitzone, relativer Zeit („in 3 Stunden“, „vor 2 Tagen“) und einem Status wie „Abgelaufen“ oder „Noch nicht gültig“ angezeigt.
4. Beachten Sie die Warnungen über den Ergebnissen, etwa wenn alg den Wert none hat oder ein Datum nach Millisekunden aussieht.
5. Um die Signatur zu prüfen, tragen Sie unter „Signatur prüfen“ den Schlüssel ein und klicken Sie auf die Schaltfläche „Signatur prüfen“.

Dekodieren ist nicht Verifizieren

Ein JWT besteht aus drei Base64url-Teilen, getrennt durch Punkte: header.payload.signature. Header und Payload sind nur kodiert, nicht verschlüsselt. Wer das Token besitzt, kann sie also lesen, und dieses Tool dekodiert jedes Token ohne Schlüssel. Das heißt aber auch: Eine dekodierte Payload beweist nichts, denn jemand könnte sie verändert haben. Erst eine gültige Signatur zeigt, dass das Token vom Inhaber des Schlüssels ausgestellt und seitdem nicht verändert wurde. Deshalb lautet die Statuszeile „Dekodiert (Signatur nicht geprüft).“, bis Sie die Signatur geprüft haben.

Ein Token mit fünf Teilen ist ein JWE (verschlüsseltes JWT). Sein Inhalt lässt sich ohne den Entschlüsselungsschlüssel nicht lesen, und das Tool weist Sie darauf hin.

Die Signatur prüfen

• HS256, HS384, HS512 (HMAC): Geben Sie das gemeinsame „Secret“ ein. Unter „Secret-Format“ legen Sie fest, ob es sich um Klartext (UTF-8) oder Base64/Base64url handelt – manche Anbieter speichern Secrets in Base64. Sie können auch ein JWK vom Typ oct einfügen. Ist das Secret kürzer als die Hash-Ausgabe (32 Byte bei HS256), weist das Tool darauf hin, dass es unter dem Minimum von RFC 7518 liegt.
• RS256/384/512, PS256/384/512, ES256/384/512 und EdDSA: Fügen Sie den „Öffentlichen Schlüssel (PEM oder JWK)“ ein. Akzeptiert werden die PEM-Blöcke PUBLIC KEY, RSA PUBLIC KEY und CERTIFICATE (dann wird der Schlüssel aus dem X.509-Zertifikat gelesen). Auch ein JWK oder ein ganzes JWK Set funktioniert: Verwendet wird der Schlüssel, dessen kid zum Header passt. Private Schlüssel werden abgelehnt, denn zum Prüfen braucht man nie einen. EdDSA unterstützt Ed25519 in Browsern, deren Web Crypto es implementiert.

Die Prüfung nutzt die Web-Crypto-API des Browsers. Das Ergebnis „Ungültige Signatur“ bedeutet: falscher Schlüssel oder verändertes Token. Beachten Sie, dass der Algorithmus hier aus dem Token-Header übernommen wird. Ein echter Server muss den erwarteten Algorithmus dagegen fest konfigurieren, sonst kann ein Angreifer ihn selbst wählen.

Sicherheitshinweise

• Tokens sind Zugangsdaten. Wer ein gültiges Access Token besitzt, kann meist bis zu dessen Ablauf im Namen des Inhabers handeln. Dieses Tool dekodiert und prüft alles in Ihrem Browser und sendet weder Token noch Schlüssel irgendwohin. Fügen Sie Produktions-Tokens trotzdem nicht in Tools ein, die Sie nicht überprüfen können.
• alg: none bedeutet, dass das Token nicht signiert ist. Jeder kann es fälschen, und ein Server muss es ablehnen. Das Tool zeigt eine Warnung und weigert sich, ein solches Token zu „verifizieren“.
• Zeitprüfungen verwenden hier die Uhr Ihres Computers ohne Toleranz; Server erlauben oft ein bis zwei Minuten Abweichung.
• JWT-Daten (NumericDate) sind Sekunden seit dem 1. Januar 1970 UTC. Ein 13-stelliger Wert ist vermutlich in Millisekunden angegeben – ein häufiger Fehler.