📋 Sommaire
Anatomie d'un JWT : En-tête, Payload, Signature
Un JSON Web Token ressemble à ceci :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Trois sections séparées par des points. Chaque section est du JSON encodé en Base64URL :
| Section | Contient | Exemple |
|---|---|---|
| En-tête (rouge) | Type de token + algorithme de signature | {"alg":"HS256","typ":"JWT"} |
| Payload (violet) | Claims — données utilisateur + métadonnées | {"sub":"123","name":"John","iat":1516239022} |
| Signature (bleu) | Signature cryptographique de l'en-tête+payload | SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c |
La signature est calculée par : HMACSHA256(base64url(header) + "." + base64url(payload), secret). Cela signifie que n'importe qui peut lire l'en-tête et le payload — ce n'est que du Base64, pas du chiffrement. Mais personne ne peut les modifier sans invalider la signature (sauf s'ils connaissent le secret).
Comment Décoder un JWT en Quelques Secondes
Vous avez trois options :
1. Utiliser un outil de décodage JWT (le plus rapide)
Collez votre token dans le Décodeur JWT iluv.tools. Il décode instantanément l'en-tête et le payload, affiche la date d'expiration en format lisible, et signale si le token est expiré. Aucune donnée ne quitte votre navigateur.
2. Console du navigateur
// Décoder le payload JWT
const token = "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.xxx";
const payload = JSON.parse(atob(token.split('.')[1]));
console.log(payload);
3. Ligne de commande
echo "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.xxx" | cut -d'.' -f2 | base64 -d 2>/dev/null | python -m json.tool
Ce Que Contient Réellement le Payload
Les claims JWT sont les paires clé-valeur dans le payload. Ils existent en trois variétés :
| Claim | Signification | Exemple |
|---|---|---|
iss (issuer) | Qui a créé le token | "auth.mysite.com" |
sub (subject) | À qui appartient le token (ID utilisateur) | "user_12345" |
aud (audience) | À qui le token est destiné | "api.mysite.com" |
exp (expiration) | Timestamp Unix d'expiration du token | 1716931200 |
iat (issued at) | Timestamp Unix de création du token | 1716927600 |
nbf (not before) | Token invalide avant ce timestamp | 1716927600 |
jti (JWT ID) | Identifiant unique pour ce token | "a1b2c3d4" |
Le claim exp est le plus important pour le débogage. Si votre API renvoie 401 Non autorisé, décodez d'abord le JWT. Vérifiez exp — convertissez le timestamp Unix en date lisible. Est-ce dans le passé ? Token expiré. Est-ce null ou manquant ? Le token n'expire peut-être jamais (courant avec des serveurs d'authentification mal configurés).
Problèmes JWT Courants et Comment les Résoudre
1. Erreurs « JWT expiré » / 401
Décodez le token. Vérifiez exp. S'il est dans le passé : le token a expiré et le client doit le rafraîchir. La plupart des serveurs d'authentification définissent exp entre 15 et 60 minutes après iat. Si exp est dans 50 ans : le serveur d'authentification est mal configuré (ou c'est un token de test).
2. Erreurs « Signature invalide »
Le token a été modifié après la signature, OU le serveur utilise un secret différent de celui qui l'a signé. Causes courantes : inadéquation de variable d'environnement (secret de développement vs secret de production), rotation de secret, ou le client a accidentellement tronqué/modifié la chaîne du token.
3. « Algorithme non supporté »
Vérifiez le champ alg de l'en-tête. S'il indique "none", le token n'est pas signé — rejetez-le. L'attaque par « algorithme none » est classique : certaines bibliothèques JWT acceptaient les tokens avec {"alg":"none"} comme valides sans vérifier la signature. Validez toujours alg par rapport à une liste blanche.
4. Inadéquation d'audience
Vérifiez aud dans le payload. Si votre API attend "api.mysite.com" mais le token indique "other-service.com", le token a été émis pour un service différent. Cela arrive dans les configurations de microservices où les tokens sont routés vers le mauvais service.
Sécurité JWT : Ce Qui Peut Mal Tourner
- Fuite de token — Les JWTs sont des bearer tokens. Quiconque possède le token peut l'utiliser. Stockez dans des cookies httpOnly, pas dans localStorage (les XSS peuvent lire localStorage). Utilisez des durées d'expiration courtes et des refresh tokens pour la longévité.
- Absence de mécanisme de révocation — Les JWTs sont sans état par conception. Une fois émis, ils sont valides jusqu'à leur expiration. Il n'existe pas de fonctionnalité intégrée de « déconnexion » ou de « révocation de ce token ». Solutions : listes noires de tokens (avec état, contredit le principe), tokens d'accès à courte durée (5-15 min) + refresh tokens révocables.
- Secrets de signature faibles — Si vous utilisez HS256 (HMAC), le secret doit être une chaîne cryptographiquement aléatoire d'au moins 256 bits (32 octets). « mysecret » ou « password123 » peut être cassé par force brute en quelques minutes.
- Attaque par algorithme none — Validez toujours
algpar rapport à une liste d'autorisation. N'acceptez jamais"none". - Attaque par confusion de clé — Si votre serveur accepte à la fois HS256 (symétrique) et RS256 (asymétrique), un attaquant peut utiliser la clé publique RS256 comme secret HS256 pour forger des tokens. Mitigation : utilisez des chemins de validation séparés, ou n'acceptez qu'un seul algorithme.