JWT-Decoder
JSON-Web-Tokens bestehen aus drei Base64url-Segmenten: header.payload.signature. Fügen Sie ein JWT ein, um Algorithmus (alg), Aussteller (iss), Betreff (sub) und Ablauf (exp) zu lesen, ohne das Token an einen Server zu senden. Dieser Decoder überprüft keine Signaturen — verwenden Sie dazu das Geheimnis deiner App oder JWKS.
JWT token
Output
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890",
"name": "Ada",
"iat": 1516239022
}
}
So entschlüsseln Sie ein JWT
1. Fügen Sie die JWT-Zeichenfolge ein (eyJ...-Format).
2. Lies den dekodierten JSON-Header (typ, alg).
3. Nutzlastansprüche lesen (Sub, Exp, Rollen).
4. Prüfe die Exp mit der aktuellen Zeit — abgelaufene Token schlagen bei der API-Authentifizierung fehl.
Beispiele für JWT-Inspektionen
Debug 401 Nicht autorisiert
Zugriffstoken dekodieren — exp kann aufgrund von Taktversatz oder kurzer TTL in der Vergangenheit liegen.
Prüfe OAuth id_token
Vom Identitätsanbieter zurückgegebene E-Mail- und Namensansprüche anzeigen.
Prüfe die Testvorrichtung
Bestätigen Sie vor dem Integrationstest, dass das HS256-Testtoken den Anspruch „role:admin“ hat.
Wann JWTs dekodiert werden sollten
• Beim Debuggen der Authentifizierung in der Entwicklung mit Testtokens.
• Beim Erlernen der JWT-Struktur und Standardansprüchen.
• Bei der Überprüfung der Nutzlast vor der Implementierung von RBAC-Prüfungen.
Sicherheitsgrenzen
• Fügen Sie Produktionstokens mit Live-Berechtigungen nicht auf nicht vertrauenswürdigen Websites ein — dieses Tool ist lokal, aber seien Sie vorsichtig.
• Wenn du eine Signaturüberprüfung benötigen, verwenden Sie serverseitige Krypto mit geheimem/öffentlichem Schlüssel.
• Wenn das Token verschlüsselt ist, ist JWE ein anderes Format als das dreiteilige JWS.
Standardmäßig registrierte Ansprüche
iss (Aussteller), sub (Betreff), aud (Zielgruppe), exp (Ablauf), nbf (nicht vorher), iat (ausgestellt bei), jti (JWT-ID). Benutzerdefinierte Ansprüche wie „Rollen“ oder „mieter_id“ sind anwendungsspezifisch.
Signaturalgorithmen
HS256 verwendet ein gemeinsames Geheimnis; RS256 verwendet ein RSA-Paar aus öffentlichem und privatem Schlüssel. Öffentliche Schlüssel werden zur Überprüfung über die JWKS-URL veröffentlicht.
Uhrversatz
APIs erlauben oft 30–60 Sekunden Spielraum für exp/nbf. Wenn im Decoder gültig, die API jedoch ablehnt, überprüfen Sie die Serveruhr und die Zeitzone.
Verlassen Sie sich niemals allein auf die Nutzlast
Clientseitige Dekodierung nur für UI-Hinweise — Autorisierungsentscheidungen müssen bei jeder Anfrage die Signatur auf dem Server überprüfen.
Häufige Fragen
Was sind die drei JWT-Teile?
Header (Algorithmus und Typ), Nutzlast (Ansprüche), Signatur (Verifizierung). Durch Punkte getrennt.
Wird das Token durch die Dekodierung validiert?
Nein — jeder kann die Nutzlast entschlüsseln; Die Signatur beweist die Integrität und den Aussteller.
Was ist ein Exp-Anspruch?
Unix-Zeitstempel in Sekunden, wenn das Token abläuft. Vergleiche mit der aktuellen UTC-Zeit.
Kein Algorithmus-Angriff?
Server müssen alg:none ablehnen — der Decoder zeigt möglicherweise weiterhin den Header zur Prüfung an.
Sensible Daten in der Nutzlast?
Die JWT-Nutzlast ist Base64 und nicht verschlüsselt — geben Sie niemals unnötig Passwörter oder personenbezogene Daten ein.
Lokale Verarbeitung?
Ja — Token wird im Browser analysiert.
Aktualisierung vs. Zugriffstoken?
Bei beiden handelt es sich oft um JWTs — dekodieren Sie sie jeweils, um festzustellen, ob sich Umfang und Lebensdauer unterscheiden.