Ein JSON-Web-Token sieht aus wie eine Wand aus zufälligen Zeichen, besteht jedoch nur aus drei Teilen codierten JSON. In diesem Leitfaden wird erklärt, was jeder Teil enthält, wie man die Standardansprüche liest und den entscheidenden Unterschied zwischen der Dekodierung eines Tokens (sicher, was dieses Tool macht) und seiner Überprüfung (benötigt ein Geheimnis, was ein Server macht) erklärt.

Die drei Teile eines Tokens

Teilen Sie ein JWT in seine Punkte auf und Sie erhalten header.payload.signatur. Der Kopfzeile ist ein kleines JSON-Objekt, das beschreibt, wie das Token signiert wurde – sein alg (Algorithmus) und typ (Typ). Der interessante Teil ist die Nutzlast: ein JSON-Objekt von Ansprüchen, das beschreibt, um wen es bei dem Token geht und wie lange es gültig ist. Die Signatur ist eine kryptografische Prüfsumme über die ersten beiden Teile.

Der Header und die Nutzlast werden nur codiert, nicht verschlüsselt. Base64url kann von jedem umgedreht werden, weshalb ein Decoder wie dieser Ihnen den Inhalt ohne Passwort anzeigen kann.

Standardaussagen werden Sie am häufigsten sehen

Die JWT-Spezifikation reserviert eine Handvoll kurzer Anspruchsnamen. iss ist der Aussteller, sub der Betreff (normalerweise eine Benutzer-ID) und aud die beabsichtigte Zielgruppe. Drei sind Zeitstempel: iat (ausgestellt am), exp (läuft ab) und nbf (nicht vorher). Sie werden seit 1970 als Sekunden gespeichert, weshalb ein Roh-Token eine große Zahl wie 1717000000 anstelle eines Datums anzeigt – dieses Tool konvertiert sie für Sie und sagt Ihnen, ob das Fenster noch geöffnet ist.

Alles andere ist ein benutzerdefinierter Anspruch: Rollen, Bereiche, Mandanten-IDs, Feature-Flags. Sie sind vollkommen gültig; Sie sind einfach nicht durch den Standard definiert, daher markiert sie die Anspruchstabelle als benutzerdefiniert.

Signiert ist nicht verschlüsselt

Ein normales JWT (ein JWS) ist signiert. Die Signatur bedeutet, dass ein Server erkennen kann, ob jemand den Header oder die Nutzdaten geändert hat – sie trägt jedoch nicht dazu bei, diese zu verbergen. Behandeln Sie die Nutzlast als öffentlich: Geben Sie niemals Passwörter, Kartennummern oder Geheimnisse hinein. Wenn der Inhalt selbst geheim sein muss, benötigen Sie einen verschlüsselten Token (einen JWE), der aus fünf Segmenten besteht und ohne den Entschlüsselungsschlüssel nicht gelesen werden kann.

Warum das Dekodieren sicher ist, das Verifizieren jedoch nicht

Zum Lesen eines Tokens ist nichts außer dem Token erforderlich, daher ist es privat und harmlos, es in Ihrem Browser durchzuführen. Die Verifizierung ist eine andere Aufgabe: Sie beweist, dass das Token authentisch und nicht abgelaufen ist, und erfordert das HMAC-Geheimnis des Ausstellers (für HS256) oder den öffentlichen Schlüssel (für RS256/ES256). Ein Browser kann diese nicht sicher speichern, und ein Server sollte niemals einem Token vertrauen, den er nicht selbst überprüft hat. Aus diesem Grund stoppt dieses Tool absichtlich beim Dekodieren – und warum Sie niemals ein Live-Produktions-Token einfügen sollten, das Sie nicht kontrollieren, da derjenige, der über ein gültiges Token verfügt, normalerweise als Sie agieren kann.