JWKS & JWT Signature Verifier

A JSON Web Key Set (JWKS) is a JSON document that publishes the public keys an Identitätsanbieter uses to sign its tokens. Each entry in the keys array is a JSON Web Key (JWK) describing one key: its type (kty), intended use (use: "sig"), algorithm (alg), and a key ID (kid).

Für eine tiefere Anleitung zum Format und wie Rotation funktioniert, lesen Sie unseren Leitfaden zu JWKS.

Für eine tiefere Anleitung zum Format und wie Rotation funktioniert, lesen Sie unseren Leitfaden zu understanding JWKS (JSON Web Key Sets).

Jedes signierte JWT trägt eine kid (Key ID) in seinem Header. Die Verifizierung verwendet sie als Lookup:

1. Lesen Sie den Header: der Verifier dekodiert den JWT-Header und liest die kid- und alg-Werte.
2. Finden Sie den Key: es scannt das JWKS nach einem Key, dessen kid übereinstimmt, importiert dann diesen Public Key.
3. Verifizieren: es prüft die Signatur über Header und Payload mit diesem Key. Jeder andere Key im Set ist irrelevant.

The kid is what makes key rotation seamless: an Identitätsanbieter can publish the new key alongside the old one, and tokens signed by either keep verifying until the old key is retired. This tool shows you the match status explicitly, and falls back to trying every signing key when the kid is missing or unmatched.

Decoding a JWT is not verification. Anyone can mint a token with any claims they like: admin: true, your user's email, a fresh expiry. The only thing that ties a token to your Identitätsanbieter is the signature, so a backend that trusts decoded claims without verifying them is effectively unauthenticated.

Wenn Sie nur den Inhalt eines Tokens inspizieren müssen, unser JWT Token Analyzer tut das. Dieses Tool geht einen Schritt weiter und beantwortet die Frage, die in der Produktion zählt: wurde dieses Token wirklich von dem Key Set signiert, dem Sie vertrauen?

In Ihren eigenen Services führen Sie diese Prüfung bei jeder Anfrage mit einer richtigen JWT-Bibliothek durch. Unser Leitfaden zu Verifizieren eines von Keycloak ausgestellten Access Tokens auf dem Backend führt durch den vollständigen serverseitigen Ablauf, einschließlich JWKS-Caching und Issuer-Checks.

Wenn eine Signaturprüfung gegen Keys fehlschlägt, von denen Sie glauben, dass sie korrekt sind, ist es normalerweise eines davon:

• kid mismatch nach Rotation: das Realm hat seinen Signing Key rotiert und das Token wurde von einem Key ausgestellt, der nicht mehr (oder noch nicht) im Set ist, das Sie abgerufen haben.
• Veralteter JWKS-Cache: Ihr Backend hat das JWKS vor einer Rotation gecacht und nie neu abgerufen. Verifizierung gegen ein frisch abgerufenes Set hier, aber Fehler in der Produktion ist das klassische Symptom.
• Wrong realm URL: fetching the JWKS from the master realm while the token was issued by another realm. Vergleichen the token's iss claim with the realm in your JWKS URL.
• Clock Skew: ein Token, das kryptografisch gültig ist, aber bei exp oder nbf abgelehnt wird, weil Issuer und Verifier über die Zeit uneins sind. Erlauben Sie ein kleines Skew-Fenster.