JWT-Decoder
Fügen Sie ein JSON Web Token ein und lesen Sie, was darin steht. Das Dekodieren passiert auf dieser Seite, in Ihrem Browser.
Ihr Token
Diese Seite dekodiert das Token und hört dort auf. Sie prüft die Signatur nicht und kann Ihnen deshalb nicht sagen, ob der im Token genannte Dienst es wirklich ausgestellt hat.
Registrierte Claims
Das läuft in Ihrem Browser. Nichts, was Sie einfügen oder öffnen, wird an uns gesendet.
Was in den drei Teilen steht
Ein JSON Web Token besteht aus drei base64url-Teilen, die mit Punkten verbunden sind. Der erste ist der Header, der in alg das Signaturverfahren und in typ den Token-Typ nennt. Der zweite ist die Payload, ein JSON-Objekt aus Claims: iss für den Aussteller, sub für die Person oder das System, um das es geht, aud für den vorgesehenen Empfänger sowie iat, nbf und exp als Sekunden seit 1970. Der dritte ist die Signatur, die aus Bytes statt aus Text besteht und sich nicht in Lesbares dekodieren lässt. Nur die registrierten Claims bekommen hier eine eigene Zeile. Alles andere aus der Payload steht oben im Payload-Block, genau so, wie es geschrieben wurde.
Dekodieren ist keine Prüfung
Header und Payload sind kodiert, nicht verschlüsselt. Wer ein Token hat, kann sie lesen, und diese Seite tut genau das. Was sie nicht kann, ist Ihnen sagen, dass das Token echt ist. Dafür braucht es das Geheimnis oder den öffentlichen Schlüssel, mit dem es signiert wurde, und das ist Sache des Dienstes, dem das Token vorgelegt wird. Lesen Sie das Folgende als Behauptung, die das Token über sich selbst aufstellt. Und behandeln Sie ein Token, das Sie irgendwo einfügen, bis zu seinem Ablauf als aktives Zugangsmittel, denn es ist weiterhin das, womit jemand als die genannte Person handeln könnte.
Erst das Token lesen, dann die Anfrage sehen, die es getragen hat
Session Replay zeichnet die Anfrage auf, die das Token getragen hat, die Antwort darauf und die Konsolenzeile daneben. Wer sich als Nächstes einen abgelehnten Aufruf ansieht, hat damit sofort alles vor sich.