Was dieses Tool prüft
- Header: Algorithmus (alg), Typ und Schlüssel-ID (kid)
- Payload: alle Claims
- exp-, iat-, nbf-Daten und Restlaufzeit
- Riskante Einstellungen wie „alg: none“ und Tokens ohne Ablauf
- Prüfung von HMAC-Signaturen (HS256/384/512)
So funktioniert es
- 01
Fügen Sie den Token ein (er beginnt mit eyJ…).
- 02
Header und Payload werden sofort dekodiert.
- 03
Bei HS*-Tokens geben Sie das Secret ein, um die Signatur zu prüfen.
Technische Details
Dekodieren ist nicht Verifizieren
Header und Payload eines JWT sind nur Base64URL-kodiert; jeder kann sie lesen. Die Sicherheit hängt davon ab, dass der Server die Signatur mit dem richtigen Schlüssel und Algorithmus prüft.
Häufige Fehler
„alg: none“ akzeptieren, den Algorithmus aus dem Token übernehmen, schwache HMAC-Secrets, langlebige Tokens ohne exp und sensible Daten im Payload sind unsere häufigsten Funde.
Datenschutz
Token und Secret bleiben im Browser; die Prüfung läuft lokal über die Web Crypto API. Teilen Sie dennoch keine Produktionstokens.
Häufige Fragen
Ist der Payload verschlüsselt?
Nein. Standard-JWT (JWS) ist nur kodiert. Nutzen Sie JWE für geheime Daten oder lassen Sie diese aus dem Token heraus.
Kann ich RS256- oder ES256-Tokens prüfen?
Das Tool prüft derzeit nur HMAC-Signaturen (HS*). Asymmetrische Signaturen benötigen den öffentlichen Schlüssel des Ausstellers (JWKS).
Wie lange sollte ein Token gelten?
Kurze Laufzeiten für Access-Tokens – Minuten – plus getrennte, widerrufbare Refresh-Tokens sind empfehlenswert.
Warum ist „alg: none“ gefährlich?
Es bedeutet einen unsignierten Token. Akzeptiert der Server ihn, kann jeder Tokens für beliebige Nutzer oder Rollen erstellen.