JWT-Decoder

Decodieren Sie ein beliebiges JSON Web Token, um Header, Payload und Claims in lesbarer Form zu untersuchen – und verifizieren Sie optional eine HMAC-Signatur (HS256/384/512). Alles bleibt in Ihrem Browser.

Codiertes Token

So verwenden Sie JWT-Decoder

1
Token einfügen
Fügen Sie ein codiertes JSON Web Token in das Eingabefeld ein. Der Decoder teilt es automatisch in Header, Payload und Signatur auf.
2
Claims lesen
Untersuchen Sie den decodierten Header und die Payload als formatiertes JSON und prüfen Sie registrierte Claims wie Ablauf- und Ausstellungszeit, die als lesbare Datumsangaben dargestellt werden.
3
Signatur verifizieren
Geben Sie bei HMAC-Token das Signiergeheimnis ein, um zu bestätigen, dass die Signatur gültig ist und das Token nicht manipuliert wurde.

4
Kopieren, was Sie brauchen
Kopieren Sie das formatierte Header- oder Payload-JSON in die Zwischenablage, um es in Tests, in der Dokumentation oder beim Debuggen zu verwenden.

JSON Web Tokens verstehen: Aufbau, Claims und Fallstricke

Drei durch Punkte getrennte Teile

Ein JSON Web Token ist eine lange Zeichenkette mit zwei Punkten darin, die es in drei Segmente aufteilen: Header, Payload und Signatur. Jedes der ersten beiden Segmente ist ein kleines JSON-Objekt, das Base64URL-codiert wurde – eine URL-sichere Variante von Base64, die ein paar Zeichen austauscht und das Auffüllen weglässt, damit das Token sauber durch Header und Query-Strings reist. Das dritte Segment ist die Signatur, die über die ersten beiden berechnet wird.

Fügen Sie ein Token ein, und der Decoder teilt es an den Punkten auf und decodiert die ersten beiden Teile per Base64URL wieder in lesbares JSON. Sie sehen Header und Payload genau so, wie der Aussteller sie geschrieben hat. Der Grund, weshalb das überhaupt möglich ist, bildet den Kern von allem, was folgt: Diese Segmente sind lediglich codiert, nicht verschlüsselt.

Der Header: Algorithmus und Typ

Der Header ist der kleinste Teil. Er deklariert in der Regel den Typ – JWT – und, was wichtiger ist, den Signieralgorithmus in seinem Feld alg. Gängige Werte sind HS256, das einen HMAC mit einem gemeinsamen Geheimnis verwendet, sowie RS256 oder ES256, die asymmetrische Schlüsselpaare nutzen, bei denen ein privater Schlüssel signiert und ein öffentlicher Schlüssel verifiziert. Der Algorithmus sagt einem Prüfer, wie die Signatur erzeugt wurde und somit, wie sie zu überprüfen ist.

Das Feld alg ist außerdem sicherheitsrelevant. Ein Token, das den Algorithmus none angibt, oder ein Angreifer, der ein Token von einem asymmetrischen auf einen symmetrischen Algorithmus umstellt, um einen naiven Prüfer dazu zu bringen, den öffentlichen Schlüssel als HMAC-Geheimnis zu verwenden, sind klassische Angriffe. Ein korrekter Prüfer legt den erwarteten Algorithmus fest, statt blind zu vertrauen, was auch immer der Header behauptet.

Die Payload und ihre registrierten Claims

Die Payload trägt die Claims – die Aussagen, die das Token macht. Ein Satz registrierter Claim-Namen ist standardisiert, damit sich verschiedene Systeme über deren Bedeutung einig sind. Der Aussteller-Claim (iss) benennt, wer das Token erstellt hat, der Subjekt-Claim (sub) gibt an, wen oder was es betrifft (oft eine Benutzer-ID), und der Zielgruppen-Claim (aud) nennt den vorgesehenen Empfänger. Daneben finden Sie üblicherweise eigene Anwendungs-Claims wie eine Rolle oder einen Mandanten.

Dieser Decoder hebt die registrierten Claims in beschrifteter, gut lesbarer Form hervor, sodass Sie die kryptischen Kurznamen nicht auswendig kennen müssen. Aussteller, Subjekt und Zielgruppe ausgeschrieben zu sehen, ist oft alles, was Sie brauchen, wenn Sie beim Debuggen ein Token überfliegen, um zu bestätigen, dass es das richtige für den richtigen Dienst ist.

Zeit-Claims: exp, iat und nbf

Drei Claims bestimmen die Lebensdauer eines Tokens, und alle sind Unix-Zeitstempel, gemessen in Sekunden – nicht in Millisekunden, was für JavaScript-Entwickler, die an Millisekundenzeit gewöhnt sind, ein häufiger Faktor-1000-Fehler ist. Der Ablauf-Claim (exp) ist der Zeitpunkt, nach dem das Token abgelehnt werden muss, der Ausstellungs-Claim (iat) hält fest, wann es erstellt wurde, und der Gültig-ab-Claim (nbf) markiert den frühesten Moment, ab dem es gültig wird.

Der Decoder wandelt diese in lesbare Datumsangaben um und teilt Ihnen mit, ob das Token gemäß der Uhr Ihres Geräts derzeit aktiv, noch nicht gültig oder abgelaufen ist. Dieses letzte Detail ist wichtig: Geht die Uhr Ihres Rechners falsch, kann das Aktiv-oder-abgelaufen-Urteil irreführend sein, und im Produktivbetrieb ist eine Zeitabweichung zwischen Servern ein häufiger Grund dafür, dass ein frisch ausgestelltes Token als noch nicht gültig abgelehnt wird.

Decodieren ist nicht Verifizieren

Dies ist das mit Abstand Wichtigste, das Sie verinnerlichen sollten. Jeder kann ein JWT decodieren – es ist nur Base64URL –, sodass das Lesen der Claims Ihnen sagt, was das Token behauptet, nicht aber, ob das Token echt ist. Vertrauen entsteht erst durch das Prüfen der Signatur gegen den Schlüssel, was belegt, dass das Token von einer Partei mit dem Geheimnis oder dem privaten Schlüssel ausgestellt und seither nicht verändert wurde.

Bei HMAC-Token (HS256, HS384, HS512) kann dieses Tool die Signatur aus Header, Payload und dem von Ihnen angegebenen Geheimnis neu berechnen und mit der Signatur des Tokens vergleichen, womit die Echtheit für dieses Geheimnis bestätigt wird. Asymmetrische Algorithmen wie RS256 und ES256 benötigen den öffentlichen Schlüssel des Ausstellers und werden hier decodiert, aber nicht verifiziert. Entscheidend ist: Echte Autorisierungsentscheidungen müssen die Signatur serverseitig verifizieren; vertrauen Sie den Claims eines Tokens im Client-Code niemals allein aufgrund des Decodierens.

Die Payload ist nicht geheim

Weil die Payload nur codiert ist, ist jeder darin enthaltene Claim für jeden, der das Token erhält, klar sichtbar – für den Browser, jeden Proxy, den Nutzer selbst. Ein JWT ist ein großartiger Ort für nicht sensible Identitäts- und Autorisierungsdaten und ein furchtbarer Ort für alles Vertrauliche. Legen Sie niemals ein Passwort, ein API-Geheimnis, eine Kreditkartennummer oder private personenbezogene Daten in die Payload, im Glauben, die Codierung schütze sie. Das tut sie nicht.

Die Signatur schützt die Integrität, nicht die Vertraulichkeit: Sie verhindert Manipulationen, verbirgt aber in keiner Weise den Inhalt. Wenn Sie wirklich ein verschlüsseltes Token benötigen, dessen Payload nicht gelesen werden kann, ist das ein anderes, schwergewichtigeres Konstrukt (JWE) – ein gewöhnliches JWT ist signiert, nicht verschlüsselt. Bewahren Sie Geheimnisse auf dem Server auf und verweisen Sie im Token stattdessen über eine undurchsichtige Kennung darauf.

Token sicher debuggen

In der täglichen Arbeit glänzt der Decoder beim Debuggen von Authentifizierungsabläufen: Bestätigen Sie, dass der richtige Nutzer im Subjekt-Claim steht, prüfen Sie, ob die Zielgruppe zu dem Dienst passt, der die Anfrage ablehnt, verifizieren Sie, ob die Scopes oder Rollen vorhanden sind, und lesen Sie den Ablauf, um zu sehen, ob ein 401 schlicht ein veraltetes Token ist. Den formatierten Header oder die Payload in einen Fehlerbericht oder ein Test-Fixture zu kopieren, ist mit einem Klick erledigt.

Alles geschieht lokal in Ihrem Browser – das Token und jedes von Ihnen eingegebene Geheimnis werden niemals hochgeladen, protokolliert oder gespeichert –, sodass das Untersuchen echter Produktiv-Token sicher ist. Behandeln Sie Token dennoch wie die Zugangsdaten, die sie sind: Ein gültiges, nicht abgelaufenes Token ist ein aktiver Schlüssel zu einem Konto, fügen Sie es also nicht in nicht vertrauenswürdige Tools ein und bevorzugen Sie abgelaufene oder Test-Token, wenn Sie Beispiele teilen.

Häufig gestellte Fragen

Was ist ein JSON Web Token (JWT)?

Ein JSON Web Token ist eine kompakte, URL-sichere Möglichkeit, Claims zwischen zwei Parteien darzustellen. Es besteht aus drei Base64URL-codierten Teilen – einem Header, einer Payload und einer Signatur –, die durch Punkte getrennt sind, und wird häufig zur Authentifizierung und Autorisierung in Web-APIs verwendet.

Gibt das Decodieren eines JWT das Passwort oder Geheimnis preis?

Nein. Header und Payload sind nur Base64URL-codiert, nicht verschlüsselt, sodass jeder sie lesen kann – deshalb sollten Sie niemals sensible Geheimnisse in einem Token speichern. Das Signiergeheimnis selbst ist nie Teil des Tokens und lässt sich durch Decodieren nicht wiederherstellen.

Wie funktioniert hier die Signaturverifizierung?

Bei HMAC-Algorithmen (HS256, HS384, HS512) berechnet das Tool die Signatur aus Header, Payload und dem von Ihnen angegebenen Geheimnis mithilfe der in Ihren Browser integrierten Web-Crypto-API neu und vergleicht sie anschließend mit der Signatur des Tokens. Asymmetrische Algorithmen wie RS256 und ES256 benötigen öffentliche Schlüssel und werden decodiert, aber nicht verifiziert.

Was bedeuten die Claims exp und iat?

exp (Ablaufzeit) und iat (Ausstellungszeit) sind registrierte Claims, die als Unix-Zeitstempel in Sekunden gespeichert werden. Dieser Decoder wandelt sie in lesbare Datumsangaben um und zeigt anhand der Uhr Ihres Geräts an, ob das Token derzeit aktiv, noch nicht gültig oder abgelaufen ist.

Wird mein Token an einen Server gesendet?

Nein. Das Decodieren und die Signaturverifizierung laufen vollständig in Ihrem Browser. Ihr Token und Ihr Geheimnis werden niemals hochgeladen, protokolliert oder gespeichert – so bleiben selbst Produktiv-Token vollkommen privat.