Wie man ein JWT decodiert, ohne seinen Token auf den Server eines Fremden zu laden

JWTs sind überall. Jedes Mal, wenn Sie sich in einer Web-App anmelden, stellt eine API Ihnen ein JSON Web Token aus, und dieser Token trägt Ihre Identität, Ihre Berechtigungen und oft ein paar persönliche Details in seinem Payload. Das Format selbst war ein Jahrzehnt lang stabil, dann folgte ein Aufregen 2024-2025 — RFC 8725 (JWT Best Current Practices) wurde eine harte Anforderung für neue Spezifikationen, die “JWTs sind schlecht”-Debatte entbrannte erneut über Session-Größen und mehrere große Anbieter wechselten zu intransparenten Token für die Browser-Nutzung. Das Ergebnis: Mehr Entwickler als je zuvor inspizieren Token von Hand. Wenn etwas schiefgeht — Ihre Session läuft zur falschen Zeit ab, eine API lehnt einen Token ab, den Sie für gültig hielten, ein Teamkollege sagt “was steht im JWT?” — macht der erste Gedanke vieler Entwickler: den Token in einen Online-Decoder einfügen.

Das Problem: Die meisten dieser Decoder senden Ihren Token an einen Server. Der Token selbst ist kein Geheimnis (er ist nur base64-kodiertes JSON), aber die Inhalte des Payload sind es oft: eine Benutzer-ID, eine E-Mail, manchmal eine Session-ID, manchmal eine Liste von Berechtigungen. Wenn Ihr Dienst JWTs zur Kommunikation mit anderen internen Diensten verwendet, könnte das Payload sogar interne Dienstnamen oder Feature-Flags enthalten.

Ein Token, der in einen Drittanbieter-Decoder eingefügt wird, ist ein kleiner Informationsleck. Meistens ist das nicht schlimm. Aber das Prinzip zählt: Sie sollten in der Lage sein, einen Token zu inspizieren, ohne jemandes anderen Infrastruktur zu vertrauen.

Wie ein JWT tatsächlich aussieht

Ein JWT sind drei base64url-kodierte Strings, getrennt durch Punkte:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Die drei Teile sind Header, Payload und Signatur. Dekodieren Sie die ersten beiden und Sie erhalten JSON:

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "12345",
  "name": "Alice",
  "iat": 1516239022
}

Die Signatur ist ein kryptographischer Hash, der beweist, dass der Token von jemandem ausgestellt wurde, der das Geheimnis kennt. Jeder kann den Payload dekodieren — das ist nicht die Sicherheitsgrenze. Die Sicherheitsgrenze ist, ob Sie die Signatur verifizieren können.

Die Unterscheidung Verifizieren vs. Dekodieren

Hier machen viele Entwickler einen Fehler. Dekodieren ist nicht Verifizieren. Ein Decoder dekodiert einfach base64 das JSON, damit Sie es lesen können. Das kann jeder, und es beweist nicht, dass der Token authentisch ist. Verifizieren ist das Überprüfen der Signatur gegen ein bekanntes Geheimnis, um zu bestätigen, dass der Token nicht manipuliert wurde.

• Um den Inhalt eines Tokens zu debuggen (welche Claims hat er, wann läuft er ab), reicht Dekodieren.
• Um einen Benutzer zu authentifizieren, brauchen Sie Verifizieren, und das muss auf einem Server passieren, dem Sie vertrauen.

Die meisten Online-Decoder-Tools dekodieren nur. Sie zeigen Header und Payload an, fragen aber nie nach Ihrem Geheimnis — weil sie nicht verifizieren, sondern Ihnen nur zeigen, was im Token steht.

Wie man lokal dekodiert

Dafür brauchen Sie kein Drittanbieter-Tool. Ein JWT sind einfach drei base64url-Strings. Öffnen Sie ein Terminal:

echo 'eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0' | tr '_-' '/+' | base64 -d

Das ist der Payload. Der Header ist das erste Segment, gleicher Trick.

Wenn Sie den tr '_-' '/+'-Tanz nicht auswendig lernen wollen, macht der JWT-Decoder auf DevSpeedTools dasselbe im Browser. Kein Netzwerk-Request, kein Upload, kein Log. Öffnen Sie DevTools → Network, fügen Sie einen Token ein und überzeugen Sie sich selbst, dass nichts Ihren Computer verlässt.

Wann Sie tatsächlich Verifizieren brauchen

Wenn Sie versuchen, ein Authentifizierungsproblem zu debuggen und wissen müssen, ob der Token gültig ist (nicht nur, was er enthält), müssen Sie die Signatur verifizieren. Die Verifizierung muss mit demselben Geheimnis oder öffentlichen Schlüssel passieren, den Ihr Authentifizierungsserver verwendet. Das bedeutet, es muss auf einer Infrastruktur passieren, die Sie kontrollieren.

Einige Optionen für Verifizierung, ohne Ihr Geheimnis in eine Website einzufügen:

• In Node.js: jsonwebtoken.verify(token, process.env.JWT_SECRET).
• In Python: jwt.decode(token, key, algorithms=['HS256']).
• In Go: token, err := jwt.Parse(tokenString, keyFunc).
• CLI: jwt-cli (Rust) oder pyjwt mit einem Einzeiler.

Wenn Sie aus irgendeinem Grund einen Online-Verifier brauchen, suchen Sie einen, der explizit sagt, dass er im Browser läuft (der Quellcode ist normalerweise sichtbar). Die ehrlichen Tools sagen das. Den Rest sollten Sie als Upload Ihres Tokens auf einen Server annehmen.

Der “invalid signature”-Fehler

Ein häufiger Grund, warum Entwickler auf einem Decoder landen, ist der Fehler invalid signature. Diese Meldung tut zwei Dinge:

1. Sie sagt Ihnen, dass der Token mit einem anderen Geheimnis signiert wurde als dem, das Sie zur Verifizierung verwenden.
2. Sie sagt Ihnen, dass der Token möglicherweise manipuliert wurde.

Oder — und das ist der, den die meisten übersehen — der Token könnte abgelaufen sein. Überprüfen Sie den exp-Claim im Payload. Wenn der aktuelle Unix-Zeitstempel nach exp liegt, ist der Token ungültig. Einige Bibliotheken werfen invalid signature für abgelaufene Token, was irreführend ist.

Der JWT-Decoder zeigt den exp-Wert zusammen mit dem Rest des Payload an, sodass Sie abgelaufene Token auf einen Blick erkennen. Dasselbe gilt für nbf (not before), iat (issued at) und aud (audience) — alles nützlich zum Debuggen.

Die Zusammenfassung

JWT-Decoder sind nützlich. Sie sind auch ein Ort, an dem Entwickler nachlässig mit dem Einfügen von Produktions-Token umgehen. Eine sicherere Standardvorgehensweise:

• Verwenden Sie einen lokalen oder Browser-basierten Decoder zur schnellen Inspektion. Kein Upload, kein Leak.
• Verwenden Sie eine CLI oder Ihren eigenen Code zur Verifizierung. Fügen Sie niemals ein Geheimnis in eine Website ein.
• Überprüfen Sie zuerst die Standard-Claims — exp-Ablauf ist die Ursache der meisten “mein Token hat plötzlich nicht mehr funktioniert”-Probleme.

Der Token ist kein Geheimnis. Die Inhalte des Token sind es oft. Behandeln Sie ihn entsprechend.