Le JWT expliqué : comment fonctionnent les JSON Web Tokens (avec exemples)

Qu'est-ce qu'un JWT ?

Un JSON Web Token (JWT) est un jeton compact qui sert à prouver son identité auprès d'une API. Après votre connexion, le serveur vous remet un JWT ; votre navigateur ou votre application le renvoie ensuite à chaque requête, généralement dans l'en-tête Authorization: Bearer .... Le serveur le vérifie et sait qui l'appelle — sans chercher de session en base de données.

Les JWT sont partout : applications web monopage, applications mobiles, OAuth et OpenID Connect (connexion Google, Microsoft, Auth0), communication entre microservices.

Les trois parties d'un JWT

Un JWT ressemble à une longue chaîne contenant deux points :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzU3NDk0MDAwLCJleHAiOjE3NTc0OTc2MDB9.signature

Chaque partie est encodée en Base64URL :

1. L'en-tête (header) — l'algorithme et le type de jeton.
2. La charge utile (payload) — les claims : qui est l'utilisateur, quand le jeton expire…
3. La signature — prouve que le jeton n'a pas été modifié.

Une fois décodées, les deux premières parties sont du simple JSON :

{ "alg": "HS256", "typ": "JWT" }

{
  "sub": "1234",
  "name": "Alice",
  "role": "admin",
  "iat": 1757494000,
  "exp": 1757497600
}

Les claims standard

Claim	Nom	Signification
iss	Issuer	Qui a émis le jeton (votre serveur d'authentification)
sub	Subject	La personne concernée (généralement l'identifiant utilisateur)
aud	Audience	À quelle API le jeton est destiné
exp	Expiration	Quand le jeton cesse d'être valide (timestamp Unix)
iat	Issued at	Quand le jeton a été créé
nbf	Not before	Le jeton n'est pas valide avant cette date
jti	JWT ID	Identifiant unique, utile pour la révocation

Les dates sont des timestamps Unix (secondes écoulées depuis le 1er janvier 1970). Pour les lire, utilisez le convertisseur de timestamp Unix — ou laissez le décodeur JWT le faire pour vous.

Comment fonctionne la signature

Le serveur calcule la signature à partir de l'en-tête, de la charge utile et d'une clé secrète (HS256) ou d'une clé privée (RS256, ES256). Si quelqu'un modifie un seul caractère de la charge utile — par exemple "role": "user" en "role": "admin" — la signature ne correspond plus et le serveur rejette le jeton.

La signature garantit donc l'intégrité (le jeton n'a pas été modifié) et l'authenticité (il a été émis par quelqu'un qui détient la clé). Elle ne cache pas le contenu.

Décoder un JWT

Le décodeur JWT affiche l'en-tête, la charge utile, les claims et la date d'expiration sous une forme lisible. Il fonctionne entièrement dans votre navigateur : le jeton n'est jamais envoyé à un serveur.

Le décodeur ne vérifie pas la signature : il faudrait pour cela le secret ou la clé publique, qui n'ont rien à faire dans un outil de navigateur. La vérification doit être faite par votre serveur.

Les erreurs de sécurité courantes

1. Mettre des données sensibles dans la charge utile — elle est lisible par tous.
2. Des jetons qui n'expirent jamais — fixez un exp court (15 minutes à 1 heure) et utilisez des refresh tokens.
3. Accepter alg: none — imposez toujours l'algorithme attendu côté serveur.
4. Un secret HS256 faible — utilisez un long secret aléatoire (au moins 256 bits) ; générez-en un avec le générateur de mots de passe.
5. Stocker le jeton dans le localStorage sans réfléchir — vulnérable aux failles XSS ; un cookie HttpOnly est souvent plus sûr pour une application web.
6. Coller des jetons de production dans n'importe quel site — un jeton valide est une clé du compte. Utilisez un outil qui fonctionne en local, et préférez des jetons expirés ou de test.

Conclusion

Un JWT, ce n'est que trois blocs Base64URL : un en-tête, une charge utile lisible et une signature qui la protège contre les modifications. Comprendre cette structure permet de déboguer un problème d'authentification en quelques secondes — et d'éviter les erreurs de sécurité qui transforment un jeton pratique en faille.