JWT-Dekodierer
Fügen Sie ein JWT ein: Header und Payload erscheinen als formatiertes JSON, Zeitangaben werden lesbar, bekannte Claims werden erklärt und schwache Einstellungen markiert. Die Dekodierung läuft im Browser, das Token wird nirgendwohin gesendet. Das Werkzeug prüft die Signatur nicht; optional kontrolliert es nur eine HS256/384/512-Signatur mit Ihrem Geheimnis.
Fügen Sie kein echtes, aktives Token ein
Ein nicht abgelaufenes Access-Token genügt jedem, der es in die Hände bekommt, um in Ihrem Namen zu handeln. Auch wenn dieses Werkzeug das Token nirgends hinsendet: Verwenden Sie Tokens aus einer Testumgebung oder abgelaufene Tokens statt solcher aus Live-Systemen.
Die Signatur wird nicht geprüft
Was hier steht, ist nur der dekodierte Inhalt; es bedeutet nicht, dass das Token echt ist. Der Payload ist nicht verschlüsselt, und dass niemand ihn verändert hat, weiß man nur bei geprüfter Signatur. Die optionale Kontrolle gilt nur für HS256/384/512; RS-, ES- und PS-Signaturen brauchen einen öffentlichen Schlüssel und werden von diesem Werkzeug nicht geprüft.
Ein Token mit drei Teilen (Header.Payload.Signatur). Ein führendes „Bearer “, Anführungszeichen und Zeilenumbrüche werden automatisch entfernt.
Die Dekodierung läuft in Ihrem Browser; Token und Geheimnis werden nirgendwohin gesendet und nicht gespeichert.
Für die Prüfung beim Empfänger
- Prüfen Sie die Signatur immer und nehmen Sie den Algorithmus aus einer festen Positivliste, nicht aus dem alg-Feld des Tokens; das schließt alg=none- und Algorithmenverwechslungs-Angriffe aus.
- Prüfen Sie exp und nbf mit einer kleinen Toleranz (z. B. 30–60 s); gleichen Sie iss und aud exakt mit den erwarteten Werten ab.
- Legen Sie keine Geheimnisse im Payload ab: Ein JWT ist kodiert, nicht verschlüsselt. Schreiben Sie Tokens nicht in Logs oder URLs.
- Nutzen Sie kurzlebige Access-Tokens und ein separates Refresh-Token; sorgen Sie für einen Widerrufsweg (jti-Liste, Schlüsselrotation) bei Abmeldung oder Verdacht.
Dieses Werkzeug dekodiert nur das Token und markiert bekannte Konfigurationsprobleme; es ersetzt weder die Prüfung von Signatur und Inhalt noch eine Autorisierungsentscheidung oder ein Sicherheitsaudit. Die Warnliste deckt nicht alle Risiken ab. Fügen Sie keine Tokens aus Live-Systemen und keine Produktionsschlüssel in eine Webseite ein.
Möchten Sie Authentifizierung, API-Sicherheit und Systemintegration gemeinsam entwerfen? Wir können Token-Laufzeit, Schlüsselrotation und Berechtigungsmodell besprechen.
Gespräch anfragen01
So funktioniert es
A
Fügen Sie ein JWT aus einer Testumgebung ein (kein Token eines Live-Systems); Header und Payload öffnen sich sofort.
B
Sehen Sie sich Zeitangaben, Gültigkeitsstatus und Warnliste an; alg=none, Felder mit Schlüsselort und ein fehlendes exp werden markiert.
C
Ist das Token HS256/384/512, können Sie optional das Testgeheimnis eingeben und sehen, ob die Signatur übereinstimmt.
02
Woraus ein JWT besteht
Ein JWT (JSON Web Token) besteht aus drei durch Punkte getrennten Teilen: dem Header (Algorithmus und Typ), dem Payload (den Feldern, also Claims) und der Signatur. Die ersten beiden Teile sind mit Base64url kodiertes JSON; die Signatur ist ein mit Geheimnis oder privatem Schlüssel signierter Digest aus Header und Payload.
Kodierung ist keine Verschlüsselung: Den Payload kann jeder lesen. Die Signatur belegt nur, dass der Inhalt nicht verändert wurde und der Schlüsselinhaber das Token erzeugt hat; Vertraulichkeit bietet sie nicht.
03
Was dieses Werkzeug leistet und was nicht
Das Werkzeug dekodiert jeden Teil aus Base64url, liest ihn als UTF-8 und parst ihn als JSON; bei Fehlern nennt es den Teil sowie Zeile und Spalte. exp, nbf und iat sind Zeitangaben in Sekunden; das Werkzeug zeigt sie in UTC und Ortszeit und berechnet anhand der Browseruhr, ob das Token abgelaufen ist.
Die Signatur wird standardmäßig nicht geprüft. Die optionale Kontrolle gilt nur für HS256, HS384 und HS512: Mit dem Geheimnis wird ein HMAC über Header.Payload berechnet und zeitkonstant verglichen. RS, ES, PS und EdDSA brauchen einen öffentlichen Schlüssel und eine gesonderte Prüfung.
04
Die häufigsten Token-Fehler
Akzeptieren von alg=none, Lesen des Algorithmus aus dem Token, langlebige Tokens ohne exp, Geheimnisse im Payload und übersprungene iss-/aud-Prüfungen sind die häufigsten Probleme. Auch den Header-Feldern jku, x5u und jwk sollte man nicht vertrauen, da sie die Wahl der Schlüsselquelle dem Verfasser des Tokens überlassen.
Die meisten Zeitprobleme stammen von Zeitabweichungen oder einer Verwechslung von Sekunden und Millisekunden: exp ist in Sekunden; Date.now() in JavaScript liefert Millisekunden und muss durch 1000 geteilt werden.
Häufige Fragen
- Wird mein Token irgendwohin gesendet?
- Nein. Dekodierung und optionale HMAC-Berechnung laufen in Ihrem Browser; Token und Geheimnis werden weder an einen Server gesendet noch gespeichert. Dennoch genügt ein echtes, nicht abgelaufenes Token, um seinen Inhaber zu imitieren; fügen Sie keine Live-Tokens in Webseiten ein, nutzen Sie Testtokens.
- Prüft dieses Werkzeug die Signatur?
- Standardmäßig nicht. Nur bei HS256/384/512-Tokens und nur, wenn Sie das Geheimnis selbst eingeben, wird die Signatur berechnet und verglichen. Signaturen mit öffentlichem Schlüssel wie RS256 und ES256 werden hier nicht geprüft. Ein sichtbarer dekodierter Payload heißt nicht, dass das Token echt ist.
- Warum ist alg=none gefährlich?
- alg=none bedeutet ein unsigniertes Token. Liest ein Empfänger den Algorithmus aus dem Token und akzeptiert none, kann ein Angreifer den Payload beliebig schreiben und ohne Signatur senden. Die Lösung ist, die akzeptierten Algorithmen beim Empfänger auf eine feste Liste zu beschränken.
- Warum liegt exp scheinbar weit in der Zukunft?
- NumericDate ist in Sekunden (seit 1970-01-01). Hat der Wert 13 Stellen, wurde er höchstwahrscheinlich in Millisekunden geschrieben, und Empfänger sehen darin ein sehr fernes Datum. Teilen Sie beim Ausstellen Date.now() durch 1000.
- Sind die Angaben im Payload geheim?
- Nein. Ein JWT kann signiert, aber nicht verschlüsselt sein; jeder, der das Base64url dekodiert, liest den Payload. Legen Sie keine sensiblen Daten wie Passwörter oder Ausweisnummern darin ab. Ist Vertraulichkeit nötig, verwendet man ein verschlüsseltes JWE (Token mit fünf Teilen); dieses Werkzeug kann sie nicht dekodieren.
- Ortszeit und UTC unterscheiden sich, was stimmt?
- Beide zeigen denselben Zeitpunkt. JWT-Zeiten sind Zeitpunkte unabhängig von jeder Zeitzone; das Werkzeug gibt UTC und die Entsprechung in der Zeitzone Ihres Browsers an. Die Gültigkeit wird aus dem Abstand zwischen Zeitpunkten berechnet, die Zeitzone ändert das Ergebnis also nicht.
Bauen wir Authentifizierung und Integrationen sicher auf
Wir entwerfen mit Ihnen API-Authentifizierung, Token-Laufzeit und Schlüsselverwaltung zwischen CRM-, ERP- und Drittsystemen. Besprechen wir Ihren bestehenden Ablauf in einem kostenlosen Erstgespräch.