Tarayıcınız güncel değil

Bu siteyi görüntülemek için tarayıcınızın veya cihazınızın işletim sisteminin güncellenmesi gerekiyor.

Your browser is out of date. Please update iOS or your browser to view this site.

Zum Hauptinhalt springen
Gizke.com
Blog

JWT-Decoder

Läuft auf Ihrem Gerät. Nichts wird gesendet.

Decodieren und untersuchen Sie JSON Web Tokens vollständig in Ihrem Browser - Header, Payload, Ablaufzeit und eine optionale Signaturprüfung, nichts wird hochgeladen.

Ein JSON Web Token (JWT) ist eine kompakte, URL-sichere Möglichkeit, Claims zwischen zwei Parteien darzustellen - verwendet in „Authorization: Bearer …“-Headern, Session-Cookies und Single Sign-on. Ein JWT besteht aus drei durch Punkte verbundenen, base64url-codierten Teilen (Header, Payload, Signatur), sodass jeder Header und Payload decodieren und lesen kann, ohne den Signaturschlüssel zu benötigen - nur das Verifizieren der Signatur erfordert ein Secret oder einen privaten Schlüssel. Dieses Tool decodiert beide Teile lokal in Ihrem Browser, erklärt die Standard-Claims, markiert ein abgelaufenes oder noch nicht gültiges Token und warnt vor der Sicherheitsfalle des „none“-Algorithmus - Ihr Token wird nie an einen Server gesendet.

Häufig gestellte Fragen

Wird mein JWT an einen Server gesendet?
Nein. Das Decodieren erfolgt vollständig in Ihrem Browser mithilfe der Web-APIs atob und TextDecoder - das Token sowie jedes Secret oder jeder öffentliche Schlüssel, den Sie zum Verifizieren einfügen, verlassen Ihr Gerät niemals.
Kann dieses Tool die Signatur verifizieren?
Ja, als zusätzliche Funktion ohne Garantie. Wenn Sie das HMAC-Secret kennen (für HS256/384/512) oder den PEM-codierten öffentlichen Schlüssel einfügen (für RS256/384/512 oder ES256/384/512), prüft das Tool die Signatur lokal mit der Web-Crypto-API des Browsers. Ohne Schlüssel werden nur Header und Payload decodiert und angezeigt - das Decodieren selbst erfordert nie den Signaturschlüssel.
Warum steht dort als Algorithmus „none“?
"alg": "none" bedeutet, dass das Token überhaupt nicht signiert ist - jeder hätte beliebige Claims hineinschreiben können. Manche Bibliotheken haben solche unsignierten Tokens früher fälschlich als gültig akzeptiert, was zu einer bekannten Methode wurde, die Authentifizierung zu umgehen. Dieses Tool markiert das immer deutlich, damit Sie es nicht übersehen.
Was bedeuten exp, iat und nbf?
Das sind die Standard-Zeitstempel-Claims aus RFC 7519: iat gibt an, wann das Token ausgestellt wurde, nbf den frühesten Zeitpunkt, ab dem es gültig ist, und exp, wann es ungültig wird. Alle drei werden als NumericDate gespeichert - Sekunden seit der Unix-Epoche -, was dieses Tool in ein lesbares Datum und eine relative Zeit wie „läuft in 2 Stunden ab“ umwandelt.
Warum kann ich die Payload ohne Secret lesen?
Weil Header und Payload eines JWT nur base64url-codiert, nicht verschlüsselt sind - Codierung ist keine Geheimhaltung. Wer das Token hat, kann die Claims bereits lesen; die Signatur beweist nur, dass die Claims nicht von jemandem ohne den Schlüssel manipuliert wurden. Legen Sie niemals etwas, das ein Angreifer nicht lesen soll, direkt in eine JWT-Payload.
Mein Token hat 3 Teile, lässt sich aber trotzdem nicht decodieren - warum?
Jedes der drei Segmente (Header, Payload, Signatur) muss gültiger base64url-Text sein, und Header sowie Payload müssen zu gültigem JSON decodieren. Dieses Tool decodiert Header und Payload unabhängig voneinander und sagt Ihnen genau, welches der beiden fehlerhaft ist und warum (fehlerhaftes base64, fehlerhaftes UTF-8 oder ungültiges JSON), statt einfach kommentarlos zu scheitern.
Für Entwickler: öffnen Sie diese Seite mit einem `token`-Parameter in der URL - z. B. gizke.com/jwt?token=eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c - und dieses Token wird automatisch vorausgefüllt. Die meisten Besucher benötigen das nicht; es dient dazu, direkt auf ein einsatzbereites Beispiel zu verlinken.

Dieses Tool teilen

BlogÜber unsKontaktNutzungsbedingungenDatenschutzerklärung