Ist es sicher, ein JWT in einen Online-Decoder einzufügen?

Du stößt auf einen Bug. Eine Anfrage scheitert mit einem 403, und der einzige Hinweis ist eine lange Zeichenkette, die mit eyJ beginnt. Du willst sehen, was drinsteckt, also greifst du zum ersten Treffer bei Google: einem Online-JWT-Decoder. Du fügst das Token ein, liest den Payload, machst weiter.

War das sicher? Die ehrliche Antwort hängt ganz davon ab, ob das Token gültig war, und kaum ein Decoder sagt dir das.

Kurz gesagt: Ein JWT zu dekodieren ist sicher. Die Daten darin sind codiert, nicht verschlüsselt, das Lesen verrät also nichts Neues. Das Risiko liegt darin, ein funktionierendes Token an einen Server zu senden, den du nicht kontrollierst, wo es protokolliert und wiederverwendet werden kann. Füge niemals Produktiv-Token in Seiten ein, die dir nicht gehören.

Was ein JWT eigentlich ist

Ein JSON Web Token besteht aus drei Teilen, die durch Punkte verbunden sind: header.payload.signature. Die ersten beiden Teile sind base64url-codiertes JSON. Base64url ist keine Verschlüsselung. Es ist ein umkehrbares Textformat, dieselbe Art von Codierung, mit der man Binärdaten in eine URL packt. Jeder Computer kann das in einer Millisekunde wieder in lesbares JSON verwandeln, ohne Schlüssel und ohne Berechtigung.

Wenn ein Decoder dir also den Payload zeigt, hat er nichts geknackt. Er hat eine öffentliche, deterministische Umwandlung ausgeführt, die dein Browser auch allein hinbekommt. Der Payload liegt offen sichtbar in jeder Anfrage, die das Token mitführt. Die Codierung existiert, damit sich die Daten sicher transportieren lassen, nicht, um sie zu verstecken.

Dieser Payload trägt meist Claims wie diese:

{
  "sub": "user_8842",
  "email": "[email protected]",
  "role": "admin",
  "exp": 1717459200
}

Benutzer-ID, E-Mail, Rolle und ein Ablaufzeitpunkt. Manchmal mehr: Mandanten-IDs, Berechtigungs-Scopes, Session-Kennungen. Nichts davon ist vor dem Token-Inhaber geheim, denn der Token-Inhaber sollst ja du sein. Der Browser speichert es, schickt es bei jeder Anfrage mit, und der Server liest genau diese Claims, um zu entscheiden, was du tun darfst.

Die Signatur ist der Teil, auf den es ankommt

Das dritte Segment ist eine kryptografische Signatur. Der Server, der das Token ausgestellt hat, hat sie mit einem geheimen Schlüssel (oder einem privaten Schlüssel) berechnet, den nur der Server kennt. Kommt ein Token zurück, berechnet der Server die Signatur erneut und prüft, ob sie übereinstimmt. Änderst du auch nur ein einziges Zeichen im Payload, ist die Signatur ungültig, und der Server weist das Token ab.

Genau das verstehen viele falschherum. Ein Decoder prüft die Signatur nicht. Er zerlegt nur die Zeichenkette und base64-dekodiert die ersten beiden Teile. Ein Decoder zeigt dir also bereitwillig ein manipuliertes Token, ein abgelaufenes Token oder kompletten Müll, den kein Server jemals akzeptieren würde. Dass im Decoder gültig aussehendes JSON erscheint, sagt nichts darüber aus, ob das Token funktioniert.

Und du kannst kein Token fälschen, indem du den dekodierten Payload bearbeitest. Wenn du deine role von user auf admin hochsetzt und neu codierst, entsteht ein Token mit kaputter Signatur. Ohne das Geheimnis des Servers kannst du keine passende erzeugen. Das ist der ganze Sinn des Signierens.

Hier ist der Haken. Du musst nichts fälschen, wenn du ein Token stehlen kannst, das bereits gültig ist. Ein gültiges, korrekt signiertes Token ist eine funktionierende Zugangsberechtigung. Wer es besitzt, kann in deinem Namen handeln, bis es abläuft. Die Signatur schützt vor Manipulation, nicht vor Diebstahl.

Wo liegt also die echte Gefahr?

Nicht im Dekodieren. Sondern in der Übertragung.

Wenn du ein Token in einen Online-Decoder einfügst, vertraust du darauf, dass das Tool es lokal in deinem Browser dekodiert. Viele tun das nicht. Etliche dieser Seiten schicken das Token an ihr Backend, dekodieren es serverseitig und schicken das Ergebnis zurück. Von deiner Seite sieht es identisch aus. Der Payload erscheint, du bist zufrieden. Währenddessen hat der Betreiber dieser Seite gerade eine voll funktionsfähige Zugangsberechtigung für deinen Account erhalten.

Was als Nächstes passiert, hast du nicht mehr in der Hand:

• Das Token kann in ein Server-Log geschrieben werden, mal versehentlich, mal absichtlich.
• Es kann gegen die echte API wiederverwendet werden. Wenn es Admin-Zugriff gewährt, dann auch die Kopie.
• Es bleibt nutzbar, bis die Zeit aus exp verstrichen ist. Kurzlebige Token begrenzen den Schaden auf Minuten. Langlebige geben einem Angreifer Stunden oder Tage.
• Manche Token laufen nie ab. Manche sind Refresh-Token, die auf Abruf brandneue Access-Token ausstellen können. So eins in den Server eines Fremden einzufügen kommt fast einer dauerhaften Übergabe des Accounts gleich.

Du wirst es wahrscheinlich nie erfahren. Für eine Zugangsberechtigung, die du freiwillig hergegeben hast, gibt es keine Meldung über eine Datenpanne. Das Dekodieren sah normal aus, der Bug wurde behoben, und eine Kopie deiner Session liegt in den Logs von jemand anderem.

Das ist keine Paranoia vor einer bestimmten bösartigen Seite. Es liegt in der Struktur der Sache. Von außen kannst du nicht erkennen, ob ein gegebener Decoder ehrlich ist, und die Kehrseite ist, falls nicht, die Übernahme deines Accounts. Wenn der Preis für einen Fehler so hoch ist, ist die richtige Grundannahme, dass das Token deinen Rechner verlassen hat.

Wie du ohne das Risiko dekodierst

Ein paar Gewohnheiten machen das zum Nichtproblem.

Nimm ein Token, das egal ist. Wenn du nur den Aufbau von JWTs verstehen oder prüfen willst, welche Claims dein Auth-Provider setzt, erzeuge ein Beispiel-Token. Es sieht echt aus und dekodiert genauso, aber es gehört zu keinem echten Account, also ist es egal, wer es sieht.

Nimm ein abgelaufenes Token. Wenn du die Session eines bestimmten Nutzers debuggst, zeigt eine abgelaufene Kopie dieselben Claims und kann nicht für den Zugriff wiederverwendet werden. Hol dir eins aus den Logs von gestern statt aus der laufenden Anfrage.

Füge niemals Produktiv- oder Live-Token in eine Seite ein, die du nicht kontrollierst. Das ist die eine Regel, die alles abdeckt. Wenn das Token aktuell gegen ein echtes System funktioniert, behandle es wie ein Passwort, denn faktisch ist es eins.

Dekodiere es selbst, wenn du kannst. Dein eigener Rechner schafft das ganz ohne Webseite. Auf der Kommandozeile:

# split on dots, base64-decode the payload (second field)
echo "$JWT" | cut -d. -f2 | base64 -d 2>/dev/null

Das berührt nie das Netzwerk. Das Token verlässt deinen Laptop nicht.

Wie du prüfst, ob ein Decoder clientseitig läuft

Wenn du der Bequemlichkeit wegen doch ein Browser-Tool willst, vergewissere dich, dass es das Token wirklich lokal hält, bevor du ihm etwas Sensibles anvertraust.

Der Offline-Test ist der einfachste Beweis. Lade die Seite, trenne dann die Internetverbindung (Wi-Fi aus oder Kabel ziehen). Füge ein Token ein. Wenn es trotzdem dekodiert, passiert die Arbeit in deinem Browser, denn es gibt keinen Server, den es erreichen könnte.

Der Netzwerk-Tab-Test ist genauer. Öffne die Entwicklertools deines Browsers, geh auf den Netzwerk-Tab, leere ihn und füge ein Token in das Tool ein. Beobachte die Anfrageliste. Ein echter clientseitiger Decoder erzeugt keine neuen ausgehenden Anfragen, die dein Token mitführen. Wenn in dem Moment, in dem du einfügst, eine Anfrage losgeht, geht das Token irgendwohin, und du solltest davon ausgehen, dass dieses Irgendwo es jetzt hat.

Beide Tests dauern unter einer Minute und klären die Frage ein für alle Mal. Ein Tool, das beide besteht, ist eines, in das du ohne Nachdenken einfügen kannst, denn nichts, was du tippst, überquert je das Netzwerk.

Wir bauen einen JWT-Decoder für dev.hivly.net, der komplett im Browser läuft, sodass Token auf deinem eigenen Rechner dekodiert und nie irgendwohin übertragen werden. Er kommt bald. Bis dahin lassen dich der Offline- und der Netzwerk-Tab-Check oben jeden Decoder prüfen, den du schon nutzt.

Die Kurzfassung: Dekodieren ist harmlos, die Daten sind nicht geheim, und du kannst kein Token durch Bearbeiten fälschen. Das Einzige, was dir schaden kann, ist, eine gültige, funktionierende Zugangsberechtigung an einen Server zu geben, den du nicht kontrollierst. Halte gültige Token auf Rechnern, die dir gehören, teste mit abgelaufenen oder Beispiel-Token und prüfe, ob dein Decoder lokal läuft. Mach das, und die Frage, ob es sicher ist, stellt sich gar nicht mehr.