Mode d'emploi
- Écrivez l'En-tête (JSON) et la Charge utile (JSON). Utilisez Régler iat sur maintenant, Régler nbf sur maintenant ou Régler exp dans pour remplir les dates.
- Choisissez l'Algorithme et saisissez le Secret. Choisissez Base64 sous Encodage du secret si le secret est écrit en Base64.
- Copiez le Jeton. Il a trois parties séparées par des points : l'en-tête, la charge utile et la signature.
- Collez un jeton dans Jeton à vérifier pour voir si sa signature correspond au secret ci-dessus.
Comment un JWT est signé
Un jeton web JSON (RFC 7519) est un en-tête et une charge utile, chacun écrit en JSON et codé en base64url (RFC 7515), réunis par un point. La signature est un HMAC de ces deux parties, fait avec le secret (RFC 7518, section 3.2). L'en-tête indique l'algorithme dans son champ alg, et cette page règle ce champ sur l'algorithme que vous choisissez.
La page écrit chaque objet JSON sous sa forme compacte avant de le coder : les octets signés sont donc la forme compacte de ce que vous avez saisi, non le texte avec ses espaces et sauts de ligne. Toute partie qui vérifie le jeton travaille sur les octets qu'elle reçoit, si bien que le jeton est valide dans les deux cas.
entrée de signature = BASE64URL(en-tête) . BASE64URL(charge utile)
signature = HMAC-SHA-256(secret, entrée de signature)
(HS384 et HS512 utilisent HMAC-SHA-384 et HMAC-SHA-512)
jeton = entrée de signature . BASE64URL(signature)
Les dates dans la charge utile
Les revendications iat (émis le), nbf (pas avant) et exp (date d'expiration) sont des NumericDate : des secondes depuis le 1er janvier 1970 à 00:00 UTC (RFC 7519, sections 2 et 4.1). Un jeton n'est pas accepté à partir de exp, ni avant nbf. Les boutons écrivent l'heure de l'horloge de votre appareil : une horloge fausse donne donc une heure fausse.
Ce que fait et ne fait pas la vérification
La vérification recalcule le HMAC de l'en-tête et de la charge utile exactement tels qu'ils ont été collés, et le compare à la signature. Elle refuse alg none et tout algorithme autre que HS256, HS384 et HS512, si bien qu'un jeton ne peut pas choisir un contrôle plus faible.
Elle ne vérifie pas le sens des revendications : que iss est l'émetteur attendu, ou que aud désigne votre service. Votre application doit contrôler ces points, comme le recommande la RFC 8725.
Exemple détaillé : HS256 avec le secret your-256-bit-secret
Avec l'en-tête {"alg": "HS256", "typ": "JWT"}, la charge utile {"sub": "1234567890", "name": "Ada Lovelace", "iat": 1516239022} et le secret UTF-8 your-256-bit-secret, la page fabrique ce jeton :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMn0.nmm0qepYRjhNji3O-jq8Pvcr7l_me1_bomw4EJucQCU
La vérification avec le même secret donne une signature valide. Le jeton n'a ni revendication exp ni nbf, donc aucune date ne peut le rendre invalide. La vérification avec un autre secret indique que la signature ne correspond pas.
Questions fréquentes
Mon secret est-il envoyé à un serveur ?
Non. Le jeton est signé dans votre navigateur, avec le SubtleCrypto du navigateur. Le secret n'est conservé que pendant que la page est ouverte : il n'est ni envoyé, ni stocké, ni journalisé.
Pourquoi la page dit-elle que la signature correspond, mais ma bibliothèque rejette le jeton ?
La bibliothèque peut contrôler les dates exp ou nbf, l'audience ou l'émetteur, ou bien lire le secret dans un autre encodage. Lisez le secret en UTF-8 ou en Base64 comme le fait votre bibliothèque, et comparez les dates avec une horloge exacte.
Pourquoi alg none est-il refusé ?
Un jeton avec alg none n'a pas de signature : n'importe qui peut donc en écrire un. Un service doit le rejeter. Cette page le refuse lors de la vérification, et sa signature écrit toujours un algorithme HMAC.
Quelle doit être la longueur du secret ?
Au moins aussi longue que la sortie du hash : 32 octets pour HS256, 48 pour HS384 et 64 pour HS512 (RFC 7518, section 3.2). La page avertit lorsque le secret est plus court.
Cette page peut-elle créer des jetons RS256 ou ES256 ?
Non. Elle signe et vérifie seulement avec un secret partagé, en HS256, HS384 ou HS512. Les jetons signés avec une clé privée RSA ou ECDSA demandent cette clé, que cette page n'accepte pas.
Quand dois-je choisir Base64 pour le secret ?
Seulement lorsque le secret est écrit en Base64, par exemple la valeur k d'une clé web JSON. Sinon, le secret est lu comme texte UTF-8 exactement tel que vous l'avez saisi, espaces compris.
Sources
- RFC 7519 (en anglais) : JSON Web Token (JWT)
- RFC 7515 (en anglais) : JSON Web Signature (JWS), appendix A.1 test vector
- RFC 7518 (en anglais) : JSON Web Algorithms (JWA), section 3.2
- RFC 8725 (en anglais) : JSON Web Token Best Current Practices
Chiffres et texte vérifiés pour la dernière fois le mardi 10 novembre 2026.