Que contient un JWT ? En-tete, payload et signature (2026)

Un JSON Web Token (JWT) ressemble a une longue chaine aleatoire, mais ce ne sont que trois morceaux colles avec des points. Le premier dit comment le jeton a ete construit. Le deuxieme, ce sont les claims - pour qui il est, quand il expire, et tout ce que l'emetteur y a mis. Le troisieme est une signature qu'un serveur de confiance peut controler. Ce guide parcourt chaque partie, les claims du quotidien, et la difference entre lire un jeton et s'y fier. Pour inspecter un vrai jeton, collez-le dans le Decodeur JWT - tout tourne dans le navigateur, rien n'est envoye.

Trois parties jointes par des points

RFC 7519 definit un JWT compact comme trois segments Base64URL separes par un point. Pas d'enveloppe extra, pas de JSON autour, et en general pas de signes egal de padding. Si vous coupez sur . vous obtenez toujours trois chaines, meme si la derniere est vide (la forme non securisee alg none).

• En-tete : metadonnees du jeton, presque toujours du JSON avec alg et typ.
• Payload : les claims. C'est ce que les API lisent vraiment.
• Signature : une etiquette cryptographique sur l'en-tete et le payload. Cet article et l'outil la traitent comme des octets opaques.

Quiconque sait ecrire du JSON peut fabriquer un en-tete et un payload et les encoder en Base64URL. C'est pourquoi les deux premieres parties sont publiques. Quiconque intercepte un JWT peut lire ces claims. Les donnees confidentielles n'ont pas leur place dans un JWT sauf si vous le chiffrez aussi (JWE), un autre format.

L'en-tete

L'en-tete dit aux verifieurs comment traiter le jeton. C'est un petit objet JSON. Apres decodage Base64URL du premier segment, vous voyez en general :

• alg - l'algorithme de signature (ou none). Valeurs courantes : HS256 (HMAC avec secret partage), RS256 ou ES256 (cles asymetriques).
• typ - en general JWT. Certains emetteurs l'omettent.
• kid - identifiant de cle optionnel pour que le serveur choisisse la bonne cle publique dans un JWKS.
• cty - type de contenu, rare, quand le payload est un JWT imbrique.

Le champ dangereux, c'est alg. Un decodeur affichera ce que le jeton declare. Un verifieur naif qui accepte alg none, ou qui laisse un attaquant passer de RS256 a HS256 et signer avec la cle publique comme si c'etait un secret HMAC, acceptera des jetons faux. C'est un bug serveur, pas un probleme qu'un decodeur navigateur peut corriger. Lisez alg comme un indice, jamais comme une preuve.

Le payload (claims)

Le payload est un autre objet JSON. Les specs JWT separent les claims enregistres (un petit vocabulaire partage) et les noms prives ou publics que votre app definit. Les horodatages sont des NumericDate : des secondes depuis 1970-01-01 UTC, pas des millisecondes.

Claims enregistres que vous verrez souvent

• iss - emetteur. Qui a cree le jeton (une URL ou le nom du serveur d'auth).
• sub - sujet. L'utilisateur ou le service dont parle le jeton.
• aud - audience. L'API ou l'app qui devrait l'accepter. Chaine ou tableau.
• exp - expiration. Refuser le jeton apres cet instant Unix.
• nbf - not before. Refuser le jeton avant cet instant Unix.
• iat - issued at. Quand l'emetteur l'a cree.
• jti - id du JWT. Un id unique pour revoquer ou dedupliquer.

Claims personnalises

Tout le reste est de la donnee applicative : name, email, role, scope, tenant ou un tableau de permissions. C'est pratique pour les API, et trivial a falsifier si vous ne faites que decoder. Un claim role: admin dans un jeton colle dans un decodeur signifie que l'emetteur (ou un attaquant) a ecrit cette chaine. Ce n'est pas une autorisation tant que le backend n'a pas verifie la signature et controle iss, aud et exp.

La signature

Le troisieme segment n'est pas du JSON. Pour HS256, c'est un HMAC-SHA256 sur la chaine ASCII header.payload avec un secret partage. Pour RS256 ou ES256, c'est une signature asymetrique sur la meme entree. Le decodeur montre le texte Base64URL brut pour comparer des jetons ; il ne recalcule ni ne verifie jamais cette etiquette. Verifier exige le secret ou la cle publique de l'emetteur, sur une machine de confiance.

Base64URL, pas le Base64 ordinaire

L'en-tete et le payload d'un JWT utilisent Base64URL (RFC 4648) : le meme encodage 6 bits que Base64, mais + devient -, / devient _, et le padding = est souvent omis. Le jeton reste ainsi sur dans les query strings et les en-tetes. Si vous collez un segment JWT dans un outil Base64 generique, restaurez d'abord les caracteres URL ou le JSON ne se decodera pas. Le Encodeur / decodeur Base64 est pour le Base64 ordinaire ; l'outil JWT applique deja l'alphabet URL.

Exemple concret

Le jeton de demo classique de la doc JWT se decode en un tout petit en-tete et payload. Apres avoir coupe sur les points et decode les deux premieres parties en Base64URL, vous obtenez :

• JSON d'en-tete : {"alg":"HS256","typ":"JWT"}
• JSON de payload : {"sub":"1234567890","name":"John Doe","iat":1516239022}
• iat 1516239022, c'est le 2018-01-18 01:30:22 UTC - le jeton a des annees de retard sur toute expiration reelle s'il y en avait une.
• Le troisieme segment est la signature HMAC. La regarder ne dit pas si le secret etait le bon.

Un prefixe Bearer ne fait pas partie du JWT. Authorization: Bearer eyJ... est une convention d'en-tete HTTP. Enlevez Bearer et l'espace, puis decodez les trois segments. Le decodeur ToolsMinify le fait pour vous.

Ce que vous pouvez lire vs ce qu'un serveur doit controler

Utilisez un decodeur pour debugger. Utilisez un verifieur pour autoriser.

1. Vous pouvez lire alg, typ et kid pour voir quelle cle l'emetteur visait.
2. Vous pouvez lire sub, email ou role pour comprendre une requete qui echoue.
3. Vous pouvez comparer exp et iat a une horloge pour voir si le jeton est perime.
4. Un serveur doit verifier la signature avec la bonne cle et le bon algorithme.
5. Un serveur doit refuser les jetons au mauvais iss ou aud, et ceux pas encore valides ou deja expires.
6. Un serveur doit traiter chaque claim comme non fiable tant que ces controles n'ont pas reussi.

Erreurs courantes

• Faire confiance aux claims vus dans un decodeur. N'importe qui assemble header.payload et laisse une signature poubelle.
• Accepter alg none ou laisser le jeton choisir l'algorithme de verification.
• Mettre des mots de passe, des secrets de session ou des donnees personnelles dans le payload. Le payload est lisible par quiconque a le jeton.
• Coller des jetons de production sur un site au hasard. Preferez un decodeur cote client pour que le jeton ne quitte pas la machine.
• Confondre ce format avec les JWT chiffres (JWE). Un JWE compact a cinq segments, pas trois.

Questions frequentes

Un JWT est-il chiffre ?

Un JWT signe standard (JWS) n'est pas chiffre. L'en-tete et le payload sont seulement encodes. Quiconque a le jeton peut lire les claims. Les jetons chiffres utilisent JWE et ont un autre aspect. Si vous collez un jeton dans un decodeur et voyez du JSON, ce n'etait pas confidentiel.

Pourquoi le decodeur refuse-t-il de verifier la signature ?

Verifier exige un secret ou la cle publique de celui qui detient la privee. Les mettre dans une page publique serait dangereux, et un badge vert "valide" sur un site non fiable apprendrait a se fier au mauvais controle. Decodez en local ; verifiez sur votre API.

Que signifie alg none ?

Cela signifie que l'emetteur (ou un attaquant) a marque le jeton comme non securise. Le troisieme segment est vide. Un decodeur peut encore montrer l'en-tete et le payload. Une API de production devrait refuser alg none, sauf raison locale et explicite d'accepter des jetons non signes.

exp et iat sont-ils en millisecondes ?

Non. Les NumericDate JWT sont des secondes depuis l'epoch Unix. Si un claim ressemble a 1.7e12, vous regardez probablement Date.now() JavaScript en millisecondes par erreur.

Puis-je reconstruire un jeton apres avoir edite le payload ?

Vous pouvez reencoder le JSON en Base64URL et joindre trois segments, mais l'ancienne signature ne correspondra plus. Sans le secret ou la cle privee de l'emetteur, le nouveau jeton est faux. C'est voulu. Les decodeurs servent a lire, pas a emettre des jetons de production.

Ou inspecter un jeton en securite ?

Utilisez une page qui decode dans le navigateur et n'envoie pas la chaine. Le Decodeur JWT de ToolsMinify le fait. Pour le guide clic par clic, voir Comment utiliser le Decodeur JWT.

Inspectez un jeton dans le navigateur

Collez un JWT pour voir en-tete, payload et signature en sections lisibles. Rien n'est envoye :

• Decodeur JWT - coupe le jeton, met en forme le JSON d'en-tete et de payload, copie chaque partie.
• Comment utiliser le Decodeur JWT - guide pas a pas du meme outil.
• Encodeur / decodeur Base64 - Base64 ordinaire, pas l'alphabet URL des JWT.
• Generateur de hash - Checksums SHA-256 dans le navigateur. Pas une signature JWT.
• Tous les outils developpeur - l'index complet de la categorie.