JWT-Dekoder

Fügen Sie einen JWT (drei base64url-kodierte Teile, die durch Punkte getrennt sind) ein, und der Dekoder zeigt den Header, das Payload und die Signatur, dekodiert und schön formatiert, zusammen mit dem erkannten Algorithmus, dem Token-Ablauf in Ihrer lokalen Zeit und ob nbf (not-before), iat (issued-at) und exp (expiry) konsistent sind. Optionale Signaturüberprüfung, wenn Sie das Geheimnis oder den öffentlichen Schlüssel haben.

So dekodieren Sie einen JWT

  1. 1

    Fügen Sie das Token ein

    Drei base64url-Strings, die durch `.` getrennt sind (header.payload.signature).

  2. 2

    Lesen Sie den dekodierten Header

    Algorithmus, Typ, Schlüssel-ID (`kid`). Der Algorithmus sagt Ihnen, welchen Schlüsseltyp Sie für die Verifizierung benötigen.

  3. 3

    Lesen Sie das Payload

    Standardansprüche (`iss`, `sub`, `aud`, `exp`, `iat`, `nbf`, `jti`) plus alle benutzerdefinierten Ansprüche, die Ihre Anwendung ausgibt.

  4. 4

    Verifizieren (optional)

    Geben Sie das HMAC-Geheimnis (für HS256/384/512) oder den öffentlichen Schlüssel (für RS256, ES256 usw.) an, um zu bestätigen, dass die Signatur gültig ist.

Anatomie eines JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNjAwMDAwMDAwfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Jedes Segment ist base64url (nicht standard base64) kodiert. Der Header ist JSON wie {"alg":"HS256","typ":"JWT"}, das Payload ist JSON wie {"sub":"1234567890","name":"Alice","iat":1600000000}, und die Signatur ist die HMAC- oder RSA-Signatur von header.payload.

Standardansprüche (RFC 7519)

Anspruch Name Hinweise
iss Aussteller Wer das Token ausgegeben hat
sub Betreff Um wen es bei dem Token geht
aud Publikum Für wen das Token gedacht ist
exp Ablaufzeit Unix-Zeitstempel; nach dieser Zeit abgelehnt
nbf Nicht vor Unix-Zeitstempel; vor dieser Zeit abgelehnt
iat Ausgestellt am Unix-Zeitstempel der Token-Erstellung
jti JWT-ID Eindeutiger Identifikator für Widerruflisten

Unterstützte Algorithmen

alg-Wert Schlüsseltype
HS256/HS384/HS512 Gemeinsames HMAC-Geheimnis
RS256/RS384/RS512 RSA-öffentlicher Schlüssel
ES256/ES384 ECDSA-öffentlicher Schlüssel
PS256/PS384 RSA-PSS-öffentlicher Schlüssel
EdDSA / Ed25519 Edwards-Kurve
none Nie vertrauen, unsignierte Tokens

Die alg: none Falle

Frühere JWT-Bibliotheken erlaubten "alg": "none" Tokens und akzeptierten sie naiv als gültig. Immer:

  • Whitelisten Sie die Algorithmen, die Ihre Anwendung akzeptiert.
  • Lehnen Sie alg: none bedingungslos ab.
  • Lehnen Sie alg: HS256 ab, wenn Ihr Verifizierungscode RS256 erwartet (der “Algorithmus-Verwirrungsangriff”).

Was JWT NICHT ist

  • Nicht verschlüsselt. Der Header und das Payload sind base64-kodiert, was trivial dekodiert werden kann. Stellen Sie niemals Geheimnisse in einem JWT ohne JWE (JSON Web Encryption) bereit.
  • Nicht widerrufbar standardmäßig. Einmal ausgegeben, ist ein JWT bis exp gültig. Für den Widerruf benötigen Sie eine schwarze Liste oder kurze Abläufe + Erneuerungstoken.
  • Kein Ersatz für Sitzungscookies in jedem Anwendungsfall. Opaque Tokens, die serverseitig gespeichert werden, sind oft einfacher und sicherer.

Häufige Fehler

  • Vertrauen auf den Header. Der kid und alg stammen vom Token selbst. Ein kompromittierter Server kann sie beliebig setzen; validieren Sie immer gegen eine feste Liste.
  • Ignorieren von nbf und iat Abweichungen. Uhrenabweichungen bedeuten, dass iat > jetzt passieren kann. Erlauben Sie einen kleinen Spielraum (30-60s).
  • Protokollierung ganzer JWTs. Das Payload enthält oft Benutzer-IDs, E-Mails, Berechtigungen, PII, die nicht in stdout gelangen sollte.
  • Verwendung von HS256 mit einem schwachen Geheimnis. Ein 16-Zeichen-Geheimnis ist in Minuten bruteforcebar. Verwenden Sie mindestens 256 Bit zufällige Entropie.

Häufig gestellte Fragen

Nein. Das Dekodieren erfolgt in Ihrem Browser. Das Token bleibt lokal, wichtig, da JWTs oft Sitzungsdaten, Benutzer-IDs und Berechtigungen enthalten.

Ja. Wenn Sie das gemeinsame HMAC-Geheimnis oder den PEM-kodierten öffentlichen Schlüssel einfügen, erfolgt die Überprüfung in Ihrem Browser. Der Schlüssel verlässt niemals Ihren Computer.

Es bedeutet, dass das Token unsigniert ist. Akzeptieren Sie niemals solche Tokens in der Produktion, sie können trivial gefälscht werden. Mehrere hochkarätige CVEs betrafen speziell Bibliotheken, die alg: none standardmäßig akzeptierten.

JWT-Signierung beweist Authentizität, nicht Vertraulichkeit. Der Header und das Payload sind base64url-kodiert, was umkehrbar ist. Für Geheimhaltung verwenden Sie JWE (JSON Web Encryption) um das JWT oder vermeiden Sie es, sensible Daten im Payload zu platzieren.

Verwandte Tools

Tool in anderen Sprachen verfügbar