Comment se lit un JWT ?
Un JWT (JSON Web Token, défini par la RFC 7519) est une chaîne en trois parties séparées par des points : l'en-tête, la charge utile et la signature. Les deux premières sont des objets JSON encodés en Base64url, une variante du Base64 sans « = » final, où « + » et « / » deviennent « - » et « _ ». Les décoder ne demande aucune clé : c'est ce que fait l'outil dès que vous collez un jeton.
en-tête.charge-utile.signatureHMAC-SHA-256(clé, en-tête + "." + charge-utile)L'en-tête dit comment le jeton est signé (champ alg, par exemple HS256). La charge utile porte les informations, appelées « claims » : sub (l'utilisateur concerné), iss (qui a émis le jeton), aud (à qui il est destiné), et les dates. La signature est calculée sur les deux premières parties telles qu'elles sont écrites dans le jeton : changer un seul caractère la rend fausse.
Les dates exp, iat et nbf
Les dates d'un JWT sont des nombres de secondes écoulées depuis le 1er janvier 1970 à minuit UTC, sans secondes intercalaires. Le décodeur les traduit dans l'heure de votre appareil et indique l'écart avec l'instant présent.
| Champ | Sens | Règle |
|---|---|---|
| exp | Expiration | Le jeton est refusé dès que cette date est atteinte. |
| nbf | Pas avant | Le jeton est refusé avant cette date. |
| iat | Émission | Date de création : elle donne l'âge du jeton. |
La RFC 7519 permet aux serveurs une petite tolérance, de quelques minutes au plus, pour les horloges mal réglées. Le décodeur n'en applique aucune : un jeton marqué « expiré » ici peut encore passer quelques instants sur un serveur tolérant.
Trois exemples
Charge utile : {"sub":"42","name":"Jeanne","iat":1791709200,"exp":1791712800}. iat vaut le 11 octobre 2026 à 9 h UTC (11 h à Paris), exp une heure plus tard. Avec la clédemo-lycos-cle-secrete-32-octets en mode Texte, la signature est valide.
Sa charge utile contient "iss":"joe" et "exp":1300819380, soit le 22 mars 2011 à 18 h 43 UTC : le décodeur le déclare expiré depuis plus de quinze ans.
Remplacez "sub":"42" par "sub":"43" dans le premier jeton en gardant sa signature : le décodeur lit la nouvelle charge sans difficulté, mais la vérification répond signature invalide. C'est tout l'intérêt de la signature.
Vérifier la signature
Pour un jeton HS256, HS384 ou HS512, la signature est un HMAC calculé avec une clé secrète partagée entre celui qui émet le jeton et celui qui le vérifie. Saisissez cette clé en texte, en Base64 (les deux alphabets sont acceptés) ou en hexadécimal, selon la forme sous laquelle vous la détenez.
Pour un jeton RS256 (signature RSA) ou ES256 (courbe elliptique P-256), la vérification se fait avec la clé publique de l'émetteur, au format JWK ou PEM « BEGIN PUBLIC KEY ». Si vous collez par erreur une clé privée JWK, seuls ses champs publics sont utilisés ; une clé privée PEM est refusée. Les autres algorithmes (RS512, PS256, EdDSA…) sont décodés mais pas vérifiés.
Le piège de alg: none
Un jeton dont l'en-tête annonce "alg":"none" n'a pas de signature : n'importe qui peut en fabriquer un avec la charge utile de son choix. La RFC 7518 interdit de les accepter par défaut, et le décodeur affiche un avertissement dès qu'il en voit un. Plus largement, un serveur ne doit jamais faire confiance au contenu d'un jeton avant d'en avoir vérifié la signature avec l'algorithme qu'il attend, et non celui que le jeton annonce.
Questions fréquentes
Un JWT est-il chiffré ?
Non, dans sa forme courante (trois parties séparées par des points). L'en-tête et la charge utile sont seulement encodés en Base64url : n'importe qui peut les lire. La signature garantit que le contenu n'a pas été modifié, pas qu'il est secret. Un JWT chiffré (JWE) compte cinq parties.
Comment savoir si un JWT a expiré ?
Regardez le champ exp de la charge utile : c'est un nombre de secondes écoulées depuis le 1er janvier 1970 à minuit UTC. Le décodeur le traduit en date et le compare à l'heure de votre appareil. Sans champ exp, le jeton n'a pas de date d'expiration.
Le décodeur envoie-t-il mon jeton quelque part ?
Non : le décodage et la vérification se font dans votre navigateur, rien n'est envoyé ni gardé dans l'adresse de la page. Par prudence, ne collez pas un jeton de production sur un site tiers, quel qu'il soit : tant qu'il n'a pas expiré, il ouvre le compte auquel il appartient.
Pourquoi la signature est-elle invalide alors que la clé est bonne ?
Vérifiez le format de la clé : une clé donnée en Base64 doit être saisie en mode Base64, pas en texte. Vérifiez aussi qu'aucune espace ni retour à la ligne ne s'est glissé dans le jeton ou la clé, et que l'algorithme de l'en-tête est bien celui utilisé par le serveur.
Peut-on vérifier un jeton RS256 ou ES256 ?
Oui, avec la clé publique du serveur : collez-la au format JWK (objet JSON) ou PEM (bloc « BEGIN PUBLIC KEY »). La clé privée n'est jamais nécessaire pour vérifier une signature.
Vérifié le 11 octobre 2026 sur nist.gov (FIPS 198-1, HMAC).
Une erreur ? Signalez-la, nous la corrigeons.