JWT dekodieren

Nein – und bei dieser Seite ist das nicht eine Funktion, sondern der eigentliche Sinn. Ein JWT ist meist ein aktiver Zugangsnachweis: Wer es besitzt, kann bis zum Ablauf in Ihrem Namen handeln. Es in einen Online-Decoder einzufügen, der es an einen Server schickt, heißt, einen funktionierenden Schlüssel auszuhändigen, und kein Versprechen, nichts zu protokollieren, kann das rückgängig machen. Dieser Decoder ist schlichtes JavaScript in der Seite, die Sie gerade sehen. Es wird nichts gespeichert, nichts protokolliert, keine Anfrage gestellt. Schalten Sie nach dem Laden der Seite Ihr WLAN aus, und alles funktioniert genauso. Das ist der einfachste Weg, die Datenschutzaussage selbst zu überprüfen, statt uns einfach beim Wort zu nehmen.

Nein, und das kann kein Online-Decoder ehrlicherweise ohne Ihren Signaturschlüssel. Dekodieren und Verifizieren sind völlig verschiedene Vorgänge. Dekodieren macht nur das Base64 des Tokens rückgängig – das kann jeder mit jedem Token, und es beweist überhaupt nichts darüber, ob das Token echt ist. Verifizieren heißt, die Signatur mit dem Geheimnis oder öffentlichen Schlüssel neu zu berechnen, mit dem sie erstellt wurde, und dieser Schlüssel sollte nie in eine Website eingefügt werden. Was Sie hier sehen, ist das, was das Token BEHAUPTET. Ob diese Angaben vertrauenswürdig sind, kann nur Ihr Server beantworten, der den Schlüssel besitzt.

Ja – vollständig, und das überrascht viele. Ein JWT ist signiert, nicht verschlüsselt. Header und Payload sind Base64, eine Kodierung ohne jedes Geheimnis, sodass jeder, der das Token abfängt, jeden Claim darin lesen kann. Die Signatur verhindert, dass jemand das Token VERÄNDERT; sie verhindert nicht, dass jemand es LIEST. Legen Sie nie etwas Vertrauliches in die Payload eines JWT: keine Passwörter, keine Kartennummern, keine persönlichen Daten, die Sie nicht auf eine Postkarte schreiben würden.

Dass das Token angibt, unsigniert zu sein – und das ist einer der gravierendsten Befunde, die diese Seite meldet. `alg: none` ist eine dokumentierte Umgehung der Authentifizierung: Ein Angreifer nimmt ein echtes Token, ändert die Payload so, dass er Administrator ist, setzt den Algorithmus auf „none“, entfernt die Signatur – und eine Bibliothek, die dem Header vertraut, akzeptiert es. Jede ernstzunehmende JWT-Bibliothek blockiert das inzwischen standardmäßig, aber Implementierungen, die `alg` vertrauen, gibt es noch. Ein Token, das mit `alg: none` ankommt, sollte als Angriff gelten, bis das Gegenteil bewiesen ist.

Das wird für Sie erledigt. `exp`, `iat` und `nbf` sind Unix-Zeitstempel – Sekunden seit 1970 –, die als bloße Zahlen unlesbar sind. Jeder wird als echtes Datum in Ihrer eigenen Zeitzone angezeigt, mit dem Hinweis, wie lange das her ist oder noch dauert, und ein abgelaufenes Token wird klar als solches benannt, statt dass Sie es selbst ausrechnen müssen. Auch ein Token ganz ohne `exp` wird markiert: Ein JWT, das nie abläuft, lässt sich nicht durch Ablauf entwerten und bleibt so lange gültig wie der Signaturschlüssel.

Dann ist es ein JWE – verschlüsselt statt nur signiert –, und sein Inhalt lässt sich ohne den Entschlüsselungsschlüssel tatsächlich nicht lesen. Die Seite erkennt diese Form und sagt Ihnen das, statt Ihnen Unsinn anzuzeigen. Fünf Teile bedeuten, dass die Payload echter Geheimtext ist; da gibt es nichts zu dekodieren.

Die registrierten sind: `iss` – wer es ausgestellt hat, `sub` – um wen es geht (meist eine Benutzer-ID), `aud` – für wen es bestimmt ist, `exp` – wann es abläuft, `nbf` – nicht gültig vor, `iat` – wann es ausgestellt wurde, und `jti` – eine eindeutige ID für das Token. Alles andere ist individuell festgelegt von dem, der das System gebaut hat. Jeder registrierte Claim ist in der Ausgabe mit seiner Bedeutung beschriftet, sodass Sie sich nicht merken müssen, welches Kürzel aus drei Buchstaben welches ist.