JWT-Decoder

Über JWTs

Ein JSON Web Token packt einen Header, eine Payload und eine Signatur in drei durch Punkte verbundene Base64URL-kodierte Segmente. Header und Payload sind nur kodiertes JSON, das jeder lesen kann, während die Signatur tatsächlich beweist, dass das Token nicht manipuliert wurde.

Das Feld alg im Header benennt den Signaturalgorithmus, aber da der Header nur dekodiertes, unverifiziertes JSON ist, kann ein Client ihm nicht vertrauen, dass er etwas Wahres aussagt — eine bekannte Klasse von JWT-Schwachstellen besteht darin, dass ein Angreifer alg auf „none“ setzt und die Signatur entfernt, in der Hoffnung, dass ein unvorsichtiger Verifizierer ein unsigniertes Token akzeptiert. Echte Verifizierung muss die Signatur gegen einen bestimmten Algorithmus und Schlüssel prüfen, den der verifizierende Server selbst gewählt hat, niemals gegen einen aus dem Token gelesenen. Die Claims exp und iat im Payload sind Unix-Zeitstempel (Sekunden seit der Epoche, nicht Millisekunden) — kombinieren Sie dieses Tool mit dem Zeitstempel-Konverter, um sie als Kalenderdaten zu lesen.

Wo Sie darauf treffen

• Einen von einem OAuth- oder OIDC-Anbieter ausgestellten Access- oder ID-Token untersuchen
• Debuggen, warum einem Token ein erwarteter Claim fehlt
• Ablaufdatum oder Aussteller eines Tokens prüfen, ohne Code zu schreiben
• Verstehen, was eine externe API oder Bibliothek tatsächlich in ihre Tokens packt

Häufige Fragen

Wird beim Dekodieren die Signatur geprüft?
Nein — es werden nur Header und Payload dekodiert, damit Sie sie lesen können. Die Signatur wird nicht geprüft, daher ist ein dekodiertes Token kein Beweis dafür, dass es echt oder noch gültig ist.

Kann ich den Claims eines nicht verifizierten Tokens vertrauen?
Nicht für sicherheitsrelevante Entscheidungen. Jeder kann ein JWT mit beliebigen Claims erstellen; erst eine gegen den Schlüssel des Ausstellers geprüfte Signatur macht den Inhalt vertrauenswürdig.

Wird das hier eingefügte Token gespeichert?
Nein. Das Dekodieren erfolgt vollständig für diese eine Anfrage; es wird nichts protokolliert oder aufbewahrt.

Kann man dem alg-Feld im Header vertrauen?
Nicht für sich allein. Der Header ist unverifiziertes, vom Angreifer kontrollierbares JSON, soweit es jemanden betrifft, der ein rohes Token liest — ein bekannter JWT-Angriff setzt alg auf „none“ und entfernt die Signatur vollständig, in der Hoffnung, dass ein Verifizierer, der dem Header blind vertraut, es als gültig akzeptiert. Korrekter Verifizierungscode legt fest, welchen Algorithmus und Schlüssel er erwartet, und übernimmt diese Entscheidung niemals aus dem Token selbst. Dieses Tool dekodiert nur zum Lesen; es trifft überhaupt keine Vertrauensentscheidungen.