JWKS & JWT Signature Verifier

A JSON Web Key Set (JWKS) is a JSON document that publishes the public keys an fournisseur d'identité 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).

Keycloak sert son JWKS sur /realms/<realm>/protocol/openid-connect/certs, et tout client peut le récupérer pour vérifier les tokens sans jamais voir une clé privée. C'est tout l'intérêt : la clé de signature reste secrète sur le serveur, tandis que la clé de vérification est publique par conception.

Pour une procédure plus approfondie du format et du fonctionnement de la rotation, lisez notre guide sur understanding JWKS (JSON Web Key Sets).

Chaque JWT signé porte un kid (ID de clé) dans son header. La vérification l'utilise comme une recherche :

1. Lire le header : le vérificateur décode le header JWT et lit les valeurs kid et alg.
2. Trouver la clé : il scanne le JWKS pour une clé dont le kid correspond, puis importe cette clé publique.
3. Vérifier : il vérifie la signature sur le header et le payload avec cette clé. Toute autre clé dans l'ensemble est sans importance.

The kid is what makes key rotation seamless: an fournisseur d'identité 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 fournisseur d'identité is the signature, so a backend that trusts decoded claims without verifying them is effectively unauthenticated.

Si vous avez seulement besoin d'inspecter le contenu d'un token, notre JWT Token Analyzer fait cela. Cet outil va un pas plus loin et répond à la question qui compte en production : ce token a-t-il vraiment été signé par l'ensemble de clés en qui vous avez confiance ?

Dans vos propres services, effectuez cette vérification sur chaque requête avec une bibliothèque JWT appropriée. Notre guide sur vérifier un access token émis par Keycloak sur le backend parcourt le flux complet côté serveur, y compris la mise en cache JWKS et les vérifications de l'émetteur.

Lorsqu'une vérification de signature échoue contre des clés que vous croyez correctes, c'est généralement l'un de ceux-ci :

• non-correspondance kid après rotation : le realm a fait tourner sa clé de signature et le token a été émis par une clé qui n'est plus (ou pas encore) dans l'ensemble que vous avez récupéré.
• Cache JWKS obsolète : votre backend a mis en cache le JWKS avant une rotation et n'a jamais refait la récupération. Vérifier contre un ensemble fraîchement récupéré ici mais échouer en production est le symptôme classique.
• Wrong realm URL: fetching the JWKS from the master realm while the token was issued by another realm. Comparer the token's iss claim with the realm in your JWKS URL.
• Décalage d'horloge : un token valide cryptographiquement mais rejeté sur exp ou nbf parce que l'émetteur et le vérificateur ne sont pas d'accord sur l'heure. Autorisez une petite fenêtre de décalage.