JWT-Decoder

Was ein JWT-Decoder tatsächlich macht

Ein JSON Web Token (JWT) sieht aus wie eine lange, undurchsichtige Zeichenkette zufälliger Zeichen, ist aber weder verschlüsselt noch eine geheime Chiffre. Es ist ein kompakter, URL-sicherer Behälter, der strukturierte Daten zwischen zwei Parteien transportiert. Fügen Sie oben ein Token in den Decoder ein, und er zerlegt diese Zeichenkette und zeigt Ihnen das echte JSON darin — die Metadaten, die Claims, für wen das Token bestimmt ist und wann es abläuft. Alles geschieht direkt in Ihrem Browser. Das Token wird nie hochgeladen, protokolliert oder irgendwohin gesendet, was sehr wichtig ist, wenn das, was Sie untersuchen, eine aktive Sitzungs-Zugangsberechtigung ist.

Drei Teile, zwei Punkte

Jedes wohlgeformte JWT besteht aus drei Base64url-kodierten Zeichenketten, durch Punkte verbunden: header.payload.signature. Dieses einzelne Punktzeichen ist es, woran Parser erkennen, wo ein Abschnitt endet und der nächste beginnt, und es ist der Grund, warum ein Token mit der falschen Anzahl an Punkten abgewiesen wird, bevor überhaupt etwas anderes gelesen wird.

Der Header ist ein winziges JSON-Objekt, das das Token selbst beschreibt. Er enthält fast immer typ (den Typ, üblicherweise JWT) und alg — den Signaturalgorithmus, etwa HS256 (HMAC mit SHA-256) oder RS256 (RSA mit SHA-256). Der Header teilt einem Prüfer genau mit, wie die Signatur erzeugt wurde.

Die Payload ist der Teil, der die meisten Leute interessiert. Sie ist ein weiteres JSON-Objekt, das die Claims enthält — Aussagen über den Nutzer und das Token. Die Spezifikation teilt Claims in registrierte (standardisierte, reservierte Namen), öffentliche und private (eigene Namen, die Sie für Ihre App erfinden). Das Dekodieren der Payload offenbart, wer angemeldet ist, welche Rolle er innehat und wann seine Sitzung endet.

Die Signatur ist das kryptografische Siegel. Sie wird über den kodierten Header und die Payload berechnet, mithilfe des Algorithmus aus dem Header sowie eines geheimen oder privaten Schlüssels. Da sie beide anderen Abschnitte abdeckt, macht jede Änderung am Header oder an der Payload — auch nur ein einziges Zeichen — sie ungültig.

Die Claims, die Sie am häufigsten sehen

Die registrierten Claims sind kurze, dreibuchstabige Namen, die in RFC 7519 definiert sind, damit verschiedene Systeme zusammenarbeiten können. Eine Handvoll taucht nahezu überall auf:

• iss — issuer: wer das Token ausgestellt hat (Ihr Auth-Server oder Identitätsanbieter).
• sub — subject: das Subjekt, um das es im Token geht, typischerweise eine stabile Benutzer-ID.
• aud — audience: der Empfänger, für den das Token bestimmt ist. Eine API sollte Tokens ablehnen, deren Audience nicht sie selbst ist.
• exp — expiration time: ein Unix-Zeitstempel, nach dem das Token nicht mehr akzeptiert werden darf.
• iat — issued at: der Unix-Zeitstempel, zu dem das Token erstellt wurde.

Sie können auch nbf (not before) und jti (eine eindeutige Token-ID) antreffen. Zeitstempel sind Sekunden seit 1970 in UTC, weshalb ein Decoder, der sie als für Menschen lesbare Daten darstellt, Ihnen die Kopfrechnerei erspart, ob ein Token bereits abgelaufen ist.

Dekodieren ist nicht Verifizieren — das ist der Teil, der Leute beißt

Diese Unterscheidung ist das Allerwichtigste, das man über JWTs verstehen muss. Dekodieren bedeutet, den Inhalt zu lesen: Es erfordert keinen Schlüssel, und jeder, der das Token besitzt, kann es tun, weil Base64url eine Kodierung ist, keine Verschlüsselung. Verifizieren bedeutet, zu beweisen, dass das Token authentisch und unverändert ist — die Signatur mit dem korrekten geheimen oder öffentlichen Schlüssel neu zu berechnen und zu bestätigen, dass sie übereinstimmt.

Dieses Tool dekodiert. Es zeigt Ihnen, was das Token sagt, nicht, ob das Token vertrauenswürdig ist. Ein Token könnte gefälscht, abgelaufen oder erneut abgespielt sein und dennoch in völlig sauber aussehendes JSON dekodieren. Treffen Sie niemals eine Autorisierungsentscheidung allein auf Basis dekodierter Claims. In der Produktion verifizieren Sie die Signatur serverseitig, prüfen exp und bestätigen, dass iss und aud Ihren Erwartungen entsprechen — mit einer geprüften Bibliothek, niemals mit selbstgebautem Zeichenkettenvergleich.

Eine Payload ist kein Tresor

Da die Payload nur Base64url-kodiert ist, kann sie von jedem gelesen werden, der das Token abfängt. Behandeln Sie alles darin als öffentlich. Legen Sie keine Passwörter, vollständigen Kreditkartennummern, geheimen Schlüssel oder sensiblen personenbezogenen Daten in JWT-Claims ab — wenn Sie es hier mit einem Klick dekodieren können, kann das jeder andere ebenso, der eine Kopie erhält. Die Signatur schützt vor Veränderung, nie vor Lesen. Wenn Sie den Payload-Inhalt wirklich verbergen müssen, ist das eine Aufgabe für JWE (verschlüsselte Tokens), eine gänzlich andere Spezifikation.

Datenschutz und verwandte Tools

Ein Token zu untersuchen ist ein sensibler Vorgang, daher läuft dieser Decoder vollständig clientseitig — das Parsen ist reines JavaScript in Ihrem Tab und nichts verlässt Ihren Rechner. Ein Sitzungstoken in ein serverbasiertes Tool einzufügen bedeutet, einer dritten Partei eine aktive Zugangsberechtigung zu übergeben, was genau das ist, was Sie vermeiden sollten. Für die zugrunde liegende Kodierung sehen Sie sich unser Base64-Tool an und entdecken Sie den Rest unserer Entwickler-Tools für weitere Hilfsmittel auf dem Gerät.

Häufig gestellte Fragen