Aller au contenu principal
Bethemesh
Sécurité & confidentialité

Vérificateur de signature JWT

Validez un JSON Web Token : signature HS256/384/512 avec le secret partagé, RS, PS ou ES 256/384/512 avec une clé publique JWK, JWKS (sélection par kid) ou PEM, puis contrôle des dates avec tolérance d’horloge, de l’émetteur et de l’audience attendus.

  • Presse-papiers

Intégrer ce widget

Personnalisez le rendu, vérifiez l’aperçu puis copiez le code.

Aperçu

Type de code d’intégration

Code à copier

Responsive et redimensionné automatiquement par Bethemesh.

HS256, HS384, HS512 : le secret partagé. RS, PS et ES : la clé publique en JWK, en JWKS (choisie par kid) ou en PEM « BEGIN PUBLIC KEY ».

Contrôles facultatifs

Fixez l’algorithme pour une validation proche de la production. Le mode automatique sert surtout à l’inspection.

Cet outil vous a-t-il été utile ?

Comment fonctionne cet outil ?

Le vérificateur JWT indique si un jeton est authentique et encore acceptable : il contrôle sa signature cryptographique puis ses claims. Il s’adresse aux développeurs back-end, intégrateurs OAuth/OpenID Connect et équipes sécurité qui veulent confirmer qu’un jeton a bien été signé par la bonne clé avant de chercher un bug ailleurs. Pour simplement lire le contenu d’un jeton, le décodeur JWT suffit.

La signature d’un JWS (RFC 7515) porte sur la chaîne « en-tête.payload » encodée en Base64URL ; les algorithmes sont définis par la RFC 7518. Pour HS256, HS384 et HS512, l’outil recalcule un HMAC avec le secret partagé et le compare à la signature. Pour RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSASSA-PSS) et ES256/384/512 (ECDSA sur P-256, P-384 et P-521), il vérifie la signature avec la clé publique via la Web Crypto API ; en ECDSA, la signature JWS est la concaténation brute R‖S, 64 octets pour ES256, et non une structure DER. Un jeton déclarant alg: none est toujours rejeté.

La clé publique peut être fournie sous trois formes : une JWK seule (RFC 7517), un JWKS {"keys":[…]} dans lequel l’outil choisit la clé dont le kid correspond à celui de l’en-tête, ou un PEM « BEGIN PUBLIC KEY » (SubjectPublicKeyInfo). Pour une validation proche de la production, choisissez un Algorithme attendu au lieu de laisser le mode Automatique : le jeton ne peut ainsi pas imposer un autre algorithme accepté via son propre champ alg. Le mode Automatique reste utile pour l’inspection. Une fois la signature validée, l’outil contrôle exp et nbf avec une tolérance d’horloge réglable (par exemple 60 secondes pour absorber un décalage entre serveurs), puis, si vous les renseignez, l’émetteur iss et l’audience aud attendus. Le résultat indique « valide » ou « invalide » avec la raison précise : signature incorrecte, kid introuvable, jeton expiré, pas encore valide, émetteur ou audience inattendus.

Comment utiliser cet outil ?

  1. Collez le JWT

    Collez le jeton complet. L’algorithme déclaré dans l’en-tête détermine le type de clé attendu : secret pour HS*, clé publique pour RS*, PS* et ES*.

  2. Fournissez la clé

    Saisissez le secret partagé, ou collez une clé publique JWK, un JWKS entier ou un PEM PUBLIC KEY. Avec un JWKS, la clé est choisie automatiquement grâce au kid.

  3. Réglez les contrôles et lisez le verdict

    Ajustez la tolérance d’horloge, ajoutez si besoin l’émetteur et l’audience attendus, puis lisez le résultat valide ou invalide avec sa raison.

Cas d'utilisation

Vérifier un jeton Auth0, Keycloak ou Entra ID

Récupérez le JWKS publié à l’adresse jwks_uri de votre fournisseur (par exemple /.well-known/jwks.json), collez-le avec le jeton et confirmez que la signature RS256 correspond bien à une clé publiée.

Déboguer une rotation de clés

Après une rotation, votre API rejette des jetons : vérifiez si le kid de l’en-tête existe encore dans le JWKS ou si le jeton a été signé par une clé retirée.

Contrôler un secret HS256 entre deux services

Un microservice refuse les jetons émis par un autre : testez le secret partagé et l’audience attendue pour savoir si le problème vient de la clé ou des claims.

Exemples

Inspection d’un JWT de test

Entrée

Jeton : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ; algorithme : HS256 ; secret : clé-incorrecte

Résultat

Signature invalide avec ce secret incorrect. Le contenu décodé comporte sub=1234567890 et iat=1516239022, sans champ exp.

Conseils et bonnes pratiques

  • Si vous n’avez qu’un certificat (BEGIN CERTIFICATE), extrayez d’abord sa clé publique, par exemple avec openssl x509 -pubkey -noout, car l’outil attend un PEM PUBLIC KEY.
  • Un secret HS256 fourni en Base64 par un fournisseur doit être utilisé avec exactement les mêmes octets que ceux ayant servi à signer : la chaîne Base64 et sa version décodée ne donnent pas la même signature.
  • Gardez une tolérance d’horloge courte (quelques dizaines de secondes à quelques minutes) : une valeur trop large revient à accepter des jetons expirés.

Sources et références

Questions fréquentes

Quelle est la différence entre décoder et vérifier un JWT ?

Décoder consiste à lire l’en-tête et le payload encodés en Base64URL, sans aucune clé. Vérifier consiste à recalculer ou contrôler la signature avec le secret ou la clé publique de l’émetteur, puis à valider exp, nbf, iss et aud. Seule la vérification prouve que le jeton n’a pas été forgé ou modifié.

Quelle clé utiliser pour vérifier un JWT RS256 ou HS256 ?

HS256 est symétrique : le même secret sert à signer et à vérifier. RS256, PS256 et ES256 sont asymétriques : l’émetteur signe avec sa clé privée et vous vérifiez avec la clé publique, généralement publiée dans un JWKS. Vous n’avez jamais besoin de la clé privée pour vérifier.

À quoi sert le kid dans l’en-tête d’un JWT ?

Le kid (key ID) indique quelle clé du JWKS a signé le jeton, ce qui permet à l’émetteur de publier plusieurs clés pendant une rotation. Lorsque vous collez un JWKS, l’outil sélectionne la clé dont le kid correspond. Si aucun kid ne correspond, la clé a probablement été retirée ou le JWKS ne vient pas du bon émetteur.

Pourquoi la signature de mon JWT est-elle invalide ?

Les causes les plus fréquentes sont une mauvaise clé (autre environnement, clé retirée), un secret mal encodé, un jeton modifié ou tronqué, ou une clé qui ne correspond pas à l’algorithme déclaré. Côté serveur, imposez toujours l’algorithme attendu plutôt que de faire confiance au champ alg, afin d’éviter les attaques par confusion d’algorithme décrites dans la RFC 8725.

Qu’est-ce que la tolérance d’horloge (leeway) ?

C’est une marge ajoutée lors du contrôle de exp et nbf pour compenser un léger décalage entre l’horloge de l’émetteur et celle du vérificateur. Avec 60 secondes de tolérance, un jeton expiré depuis 30 secondes est encore accepté. La plupart des bibliothèques utilisent une valeur entre 0 et 5 minutes.

Puis-je coller une clé ou un secret dans cet outil ?

Une clé publique n’est pas secrète et peut être collée sans risque. Un secret HMAC l’est : ici la vérification s’exécute dans votre navigateur avec la Web Crypto API et rien n’est transmis, mais évitez malgré tout d’utiliser un secret de production sur un poste partagé.

Workflow recommandé

Continuez votre traitement

Découvrez les outils qui interviennent naturellement avant, après ou en complément de celui-ci.

À utiliser avant

Décodeur JWT

Décodez un JWT pour lire son en-tête, son payload, ses claims et ses dates d’expiration.

Sécurité & confidentialitéMis en avantUtiliser l’outil

Fonctionne bien avec

Inspecteur JWK / JWKS

Analysez une clé JWK ou un JWKS : kid, kty, alg, use, empreinte RFC 7638 et alerte si une clé privée est exposée.

Sécurité & confidentialitéUtiliser l’outil

Encodeur JWT

Créez et signez un JWT HS256, HS384 ou HS512 à partir d’un en-tête, d’un payload JSON et d’un secret.

Sécurité & confidentialitéUtiliser l’outil

À lire aussi