Vérificateur de signature JWT HS256 | Confirmez la signature d'un jeton avec votre secret

Recalculez le HMAC-SHA-256 de header.payload avec votre secret partagé et comparez le résultat à la troisième partie du jeton. La vérification de signature indique l'un des trois états — valide, écart ou un alg différent de HS256 — tandis que l'en-tête et la charge utile sont décodés et affichés en JSON formaté.

💡 À propos de cet outil

Le plus délicat dans le débogage d'un JWT n'est pas de le lire, mais de savoir si la signature est réellement correcte. Un décodeur ouvre les segments base64url et affiche les données, mais une charge utile décodée ne dit rien sur la validité de la signature : il faut la recalculer avec le secret.

Cet outil prend la partie header.payload, exécute HMAC-SHA-256 dessus avec le secret que vous fournissez, encode le MAC en base64url et le compare comme chaîne à la signature en fin de jeton. En cas de correspondance, il affiche valide ; toute différence affiche écart ; et un en-tête dont l'alg n'est pas HS256 est rejeté comme alg non pris en charge. Modifiez un caractère du secret ou la charge utile et le verdict bascule, ce qui permet d'isoler la valeur qui casse la signature.

Le périmètre se limite à HS256 (la famille HMAC). RS256 et ES256 sont des schémas à clé publique et à courbe elliptique vérifiés avec une paire de clés plutôt qu'un secret partagé : ils sortent du cadre de cet outil ; lorsque l'alg est l'un d'eux, vous obtenez l'état alg non pris en charge plutôt qu'un résultat trompeur.

🧐 Questions fréquentes

Q. En quoi est-ce différent d'un décodeur ? Un décodeur décode l'en-tête et la charge utile en base64url et les affiche. Il ne recalcule jamais la signature. Cet outil exécute le HMAC et vous dit si la signature correspond.

Q. Pourquoi mon jeton ressort-il en écart ? Le plus souvent un secret erroné, une charge utile modifiée, une copie tronquée ayant perdu les derniers caractères, ou un . mal placé entre les segments. Annulez les changements un par un pour trouver la cause.

Q. Quelle forme prend le secret ? Saisissez le secret partagé HS256 sous la même chaîne UTF-8 que celle utilisée côté signature. Si votre pile stocke la clé en base64, collez la chaîne exacte que l'émetteur transmet comme clé plutôt que de la réencoder.

Q. Vérifie-t-il l'expiration (exp) ? Non : il vérifie uniquement l'égalité de la signature. La validation des claims comme exp et nbf est hors périmètre ; lisez-les vous-même dans le JSON de la charge utile décodée.

Q. Et un jeton dont l'alg vaut none ? Tout alg autre que HS256, y compris none, renvoie alg non pris en charge. Accepter none est une faille connue, les vérificateurs devraient donc le refuser d'emblée.

📚 Le saviez-vous

Le « HS » de HS256 signifie HMAC using SHA-256, et la spécification des algorithmes JWA (RFC 7518, §3.1) en fait le seul algorithme à implémentation obligatoire : toute bibliothèque JWT conforme doit le prendre en charge. Un même secret partagé signe et vérifie, d'où sa popularité dans les petits services, mais cela impose que l'émetteur et le vérificateur détiennent la même clé : en cas de fuite, n'importe qui peut forger des jetons valides. Détail souvent négligé : la signature porte sur le signing input — l'en-tête et la charge utile reliés par un . —, si bien que le troisième segment est un MAC dérivé de cette chaîne, et non la charge utile elle-même.

Le JWT et le secret que vous collez restent dans votre navigateur et ne sont jamais envoyés à un serveur ; le HMAC s'exécute localement via l'API Web Crypto standard.