JWT-Decoder

JSON Web Token einfügen und sofort sehen, was darin steht: Header, Payload und Signatur getrennt, jeder Claim erklärt, Ablaufzeiten als echtes Datum. Auf Wunsch wird auch die Signatur geprüft – alles lokal in deinem Browser.

Woraus ein JSON Web Token besteht

Ein JWT ist kein Geheimnis, sondern eine Nachricht mit Echtheitsnachweis. Es besteht aus drei Teilen, getrennt durch Punkte: dem Header, der das Signaturverfahren nennt, derPayload mit den eigentlichen Aussagen über den Nutzer (den Claims) und derSignatur. Header und Payload sind lediglich Base64url-kodiertes JSON – kodiert, nicht verschlüsselt. Jeder, der ein Token in die Hand bekommt, kann es lesen. Genau das macht dieser Decoder sichtbar.

Geschützt ist allein die Unverfälschtheit: Die Signatur wird über die ZeichenketteHeader.Payload gebildet. Ändert jemand ein einziges Zeichen an einem der beiden Teile, passt die Signatur nicht mehr. Deshalb gehören Passwörter, Schlüssel oder andere Geheimnisse niemals in die Payload eines JWT.

Registrierte Claims und was sie bedeuten

RFC 7519 definiert eine Handvoll Claims mit fester Bedeutung: iss (Aussteller),sub (Subjekt, meist die Benutzer-ID), aud (Zielgruppe), exp(Ablaufzeitpunkt), nbf (nicht gültig vor), iat (Ausstellungszeitpunkt) undjti (eindeutige Token-ID). Die Zeitangaben sind NumericDate-Werte, also Sekunden seit dem 1. Januar 1970 – als nackte Zahl schwer zu lesen. Dieses Werkzeug zeigt sie deshalb zusätzlich als Datum und als Abstand zu jetzt („läuft ab in 42 Minuten“).

Alles darüber hinaus ist anwendungsspezifisch. Aus OpenID Connect kommen etwa nonce,azp, auth_time und at_hash hinzu, aus OAuth 2.0 derscope. Claims wie roles, groups oder permissionssind reine Konvention und bedeuten in jedem System etwas anderes.

Signatur prüfen: symmetrisch oder asymmetrisch

Ob ein Token echt ist, entscheidet einzig die Signatur – und die lässt sich nur mit dem passenden Schlüssel prüfen. Bei den HS-Verfahren (HS256, HS384, HS512) ist das ein HMAC mit einem gemeinsamen Geheimnis: Wer prüfen kann, kann auch signieren. BeiRS, PS, ES und EdDSA genügt zum Prüfen der öffentliche Schlüssel, signieren kann nur der Besitzer des privaten. Deshalb liefern Identity Provider ihre Schlüssel als JWK-Set unter /.well-known/jwks.json aus.

Die Prüfung läuft hier über die Web-Crypto-API deines Browsers. Als Schlüssel akzeptiert das Werkzeug ein rohes Geheimnis (UTF-8, Base64, Base64url oder Hex), ein PEM im SPKI-Format („BEGIN PUBLIC KEY“), eine einzelne JWK oder ein vollständiges JWK-Set – bei letzterem wird der zur kid im Header passende Schlüssel automatisch herausgesucht.

Häufige Fragen

Wird mein Token hochgeladen?
Nein. Dekodierung und Signaturprüfung passieren vollständig in deinem Browser, es gibt keinen Server, der etwas entgegennehmen könnte. Weder Token noch Schlüssel werden gespeichert – gemerkt wird nur, ob du Zeiten in UTC anzeigen lässt.

Ist ein Token damit „entschlüsselt“?
Nein, und das ist ein verbreitetes Missverständnis. Ein normales JWT (genauer: ein JWS) ist gar nicht verschlüsselt, sondern nur kodiert. Dekodieren ist deshalb kein Angriff, sondern das vorgesehene Verhalten. Wirklich verschlüsselte Tokens gibt es als JWE – die haben fünf statt drei Teile und lassen sich ohne den privaten Schlüssel des Empfängers nicht lesen.

Was bedeutet alg: none?
Dass das Token unsigniert ist. Historisch war das die Grundlage einer ganzen Klasse von Sicherheitslücken: Bibliotheken akzeptierten Tokens, bei denen ein Angreifer den Algorithmus einfach auf none gesetzt und die Signatur entfernt hatte. Ein prüfender Dienst sollte den erwarteten Algorithmus deshalb immer selbst vorgeben, statt ihn dem Header zu entnehmen.

Das Token ist abgelaufen – ist es damit ungültig?
Für die Zeit-Claims ja. Ob es echt ist, sagt das aber nichts: Ein abgelaufenes Token kann eine gültige Signatur haben, ein noch frisches eine gefälschte. Dieses Werkzeug hält beides deshalb bewusst auseinander – „Zeitfenster“ und „Signatur prüfen“ sind zwei getrennte Aussagen.