Validiere ein JSON Web Token: Signaturen HS256/384/512 mit dem gemeinsamen Secret, RS, PS oder ES 256/384/512 mit einem öffentlichen Schlüssel als JWK, JWKS (Auswahl per kid) oder PEM, danach Prüfung der Zeitangaben mit Uhrentoleranz sowie des erwarteten Ausstellers und der Zielgruppe.
HS256, HS384, HS512: das gemeinsame Geheimnis. RS, PS und ES: der öffentliche Schlüssel als JWK, JWKS (Auswahl per kid) oder PEM „BEGIN PUBLIC KEY“.
Lege den Algorithmus für eine produktionsnahe Prüfung fest. Der automatische Modus dient vor allem zur Analyse.
algtypkidisssubaudexpiatnbfDer JWT-Verifizierer zeigt dir, ob ein Token echt und noch akzeptabel ist: Er prüft zuerst die kryptografische Signatur und dann die Claims. Er richtet sich an Backend-Entwickler, OAuth-/OpenID-Connect-Integratoren und Security-Teams, die sicherstellen wollen, dass ein Token mit dem richtigen Schlüssel signiert wurde, bevor sie den Fehler woanders suchen. Willst du nur den Inhalt lesen, reicht der JWT-Decoder.
Eine JWS-Signatur (RFC 7515) wird über den Base64URL-String „Header.Payload“ gebildet; die Algorithmen legt RFC 7518 fest. Bei HS256, HS384 und HS512 berechnet das Tool mit dem gemeinsamen Secret erneut einen HMAC und vergleicht ihn mit der Signatur. Bei RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSASSA-PSS) und ES256/384/512 (ECDSA auf P-256, P-384 und P-521) prüft es die Signatur mit dem öffentlichen Schlüssel über die Web Crypto API; bei ECDSA ist die JWS-Signatur die rohe Verkettung R‖S, 64 Byte für ES256, keine DER-Struktur. Ein Token mit alg: none wird immer abgelehnt.
Den öffentlichen Schlüssel kannst du auf drei Arten angeben: als einzelnen JWK (RFC 7517), als JWKS {"keys":[…]}, aus dem das Tool den Schlüssel mit dem passenden kid aus dem Header wählt, oder als PEM „BEGIN PUBLIC KEY“ (SubjectPublicKeyInfo). Für eine produktionsnahe Prüfung wählst du einen Erwarteten Algorithmus statt des automatischen Modus: So kann das Token nicht über sein eigenes alg-Feld einen anderen unterstützten Algorithmus vorgeben. Der automatische Modus bleibt für die Analyse nützlich. Ist die Signatur gültig, prüft das Tool exp und nbf mit einer einstellbaren Uhrentoleranz (zum Beispiel 60 Sekunden, um Zeitabweichungen zwischen Servern auszugleichen) und, falls angegeben, den erwarteten Aussteller iss und die Zielgruppe aud. Das Ergebnis lautet „gültig“ oder „ungültig“ mit dem genauen Grund: falsche Signatur, kid nicht gefunden, abgelaufen, noch nicht gültig, unerwarteter Aussteller oder unerwartete Zielgruppe.
Füge das vollständige Token ein. Der im Header angegebene Algorithmus bestimmt den erwarteten Schlüsseltyp: ein Secret für HS*, ein öffentlicher Schlüssel für RS*, PS* und ES*.
Gib das gemeinsame Secret ein oder füge einen öffentlichen JWK, ein ganzes JWKS oder ein PEM PUBLIC KEY ein. Bei einem JWKS wird der Schlüssel automatisch über den kid gewählt.
Stelle die Uhrentoleranz ein, ergänze bei Bedarf den erwarteten Aussteller und die Zielgruppe und lies dann das Ergebnis gültig oder ungültig mit seinem Grund.
Hol dir das JWKS unter der jwks_uri deines Anbieters (zum Beispiel /.well-known/jwks.json), füge es zusammen mit dem Token ein und bestätige, dass die RS256-Signatur zu einem veröffentlichten Schlüssel passt.
Nach einer Rotation lehnt deine API Tokens ab: Prüfe, ob der kid aus dem Header noch im JWKS steht oder ob das Token mit einem zurückgezogenen Schlüssel signiert wurde.
Ein Microservice lehnt die Tokens eines anderen ab: Teste das gemeinsame Secret und die erwartete Zielgruppe, um herauszufinden, ob der Schlüssel oder die Claims das Problem sind.
Eingabe
JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c; Erwarteter Algorithmus: HS256; Geheimnis oder öffentlicher Schlüssel: falscher-schluesselErgebnis
Token abgelehnt – Ungültige Signatur: Das Token wurde verändert oder der Schlüssel passt nicht. Die Token-Angaben enthalten sub=1234567890 und iat=1516239022, aber kein exp-Feld.Beim Dekodieren liest du Header und Payload aus der Base64URL-Kodierung, ganz ohne Schlüssel. Beim Prüfen wird die Signatur mit dem Secret oder dem öffentlichen Schlüssel des Ausstellers kontrolliert, danach werden exp, nbf, iss und aud validiert. Nur die Prüfung beweist, dass das Token weder gefälscht noch verändert wurde.
HS256 ist symmetrisch: Dasselbe Secret signiert und prüft. RS256, PS256 und ES256 sind asymmetrisch: Der Aussteller signiert mit seinem privaten Schlüssel, und du prüfst mit dem öffentlichen, der meist in einem JWKS veröffentlicht ist. Den privaten Schlüssel brauchst du zum Prüfen nie.
Der kid (Key ID) gibt an, welcher Schlüssel aus dem JWKS das Token signiert hat, sodass der Aussteller während einer Rotation mehrere Schlüssel veröffentlichen kann. Fügst du ein JWKS ein, wählt das Tool den Schlüssel mit dem passenden kid. Passt keiner, wurde der Schlüssel vermutlich zurückgezogen oder das JWKS stammt nicht vom richtigen Aussteller.
Die häufigsten Ursachen sind ein falscher Schlüssel (andere Umgebung, zurückgezogener Schlüssel), ein falsch kodiertes Secret, ein verändertes oder abgeschnittenes Token oder ein Schlüssel, der nicht zum angegebenen Algorithmus passt. Erzwinge auf dem Server immer den erwarteten Algorithmus, statt dem Feld alg zu vertrauen, um die in RFC 8725 beschriebenen Algorithm-Confusion-Angriffe zu verhindern.
Das ist ein Spielraum bei der Prüfung von exp und nbf, der kleine Abweichungen zwischen der Uhr des Ausstellers und der des Prüfers ausgleicht. Mit 60 Sekunden Toleranz wird ein Token, das vor 30 Sekunden abgelaufen ist, noch akzeptiert. Die meisten Bibliotheken nutzen einen Wert zwischen 0 und 5 Minuten.
Ein öffentlicher Schlüssel ist nicht geheim und kann bedenkenlos eingefügt werden. Ein HMAC-Secret schon: Hier läuft die Prüfung in deinem Browser mit der Web Crypto API und nichts wird übertragen, trotzdem solltest du auf einem geteilten Rechner kein Produktions-Secret verwenden.
Empfohlener Workflow
Entdecke Werkzeuge, die sinnvoll vor, nach oder ergänzend zu diesem Werkzeug eingesetzt werden können.
Dekodiere ein JWT und lies Header, Payload, Claims und Ablaufdaten.
Analysiere einen JWK oder ein JWKS: kid, kty, alg, use, RFC-7638-Thumbprint und Warnung bei offengelegtem privatem Schlüssel.
Erstelle und signiere ein JWT mit HS256, HS384 oder HS512 aus Header, JSON-Payload und Secret.
Lerne, was ein JWT enthält, warum Dekodieren keine Verifikation ist und wie Claims wie exp, nbf, iss und aud funktionieren.
Verstehe das Zusammenspiel von OAuth 2.0, PKCE, JWT, JWK und JWKS bei Autorisierung, Tokens, Schlüsseln und Verifizierung.
Verstehe, wann Verschlüsselung, Hashing, HMAC oder PBKDF2 für Vertraulichkeit, Integrität, Authentifizierung und Passwörter eingesetzt werden.