JWT

JWT (JSON Web Token, prononcé “jot”) est un format de jeton défini dans RFC 7519 pour transmettre des claims signés entre parties. Un JWT est trois segments encodés en base64url séparés par des points : en-tête.charge utile.signature.

L’en-tête déclare l’algorithme de signature (HS256, RS256, ES256, etc.). La charge utile est un objet JSON de claims — sub (sujet), iss (émetteur), exp (expiration), iat (émis à), plus tout champ spécifique à l’application. La signature est calculée sur base64url(en-tête) + "." + base64url(charge utile) en utilisant l’algorithme et la clé déclarés dans l’en-tête.

Les JWT sont utilisés pour l’authentification sans état (le serveur n’a pas besoin de stocker les sessions ; il vérifie la signature à chaque requête), l’autorisation inter-services (jetons bearer OAuth 2.0, jetons ID OpenID Connect), et les URL de courte durée encodant des claims d’accès.

Pièges courants : faire confiance à alg: none, accepter des jetons à clé symétrique là où l’asymétrique était attendu, ne pas valider exp. Le décodeur JWT inspecte le contenu d’un jeton — il ne vérifie pas la signature, car la vérification requiert la clé de l’émetteur.

Exemple concret

Décodez le JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTcxNjQwMDAwMCwiZXhwIjoxNzE2NDg2NDAwfQ.signature. En-tête : {"alg":"HS256","typ":"JWT"}. Charge utile : {"sub":"12345","name":"Alice","iat":1716400000,"exp":1716486400}. Le jeton a été émis au temps Unix 1716400000 (un moment en mai 2024) et expire 86 400 secondes plus tard — exactement 24 heures. Un vérificateur recevant ce jeton doit : (1) recalculer HMAC-SHA256 de en-tête.charge utile avec le secret partagé et vérifier qu’il correspond à la signature ; (2) vérifier exp par rapport à l’heure actuelle et rejeter si expiré ; (3) optionnellement vérifier que iss (émetteur) et aud (audience) correspondent aux valeurs attendues. Quiconque — y compris le navigateur de l’utilisateur, tout proxy intermédiaire, ou un attaquant qui vole le jeton — peut décoder en base64 la charge utile et voir le nom et l’identifiant utilisateur d’Alice. Le jeton est signé, pas chiffré.

Quand et pourquoi c’est important

JWT importe chaque fois que l’authentification sans état est le choix de conception — typique pour les SPA communiquant avec des API REST, les applications mobiles avec des services backend, les fédérations OAuth 2.0 / OpenID Connect, et l’autorisation service-à-service. Les erreurs à éviter : (1) mettre des DCP ou des données sensibles dans la charge utile (elle est lisible par quiconque possède le jeton) ; (2) utiliser de longues durées d’expiration sans stratégie de révocation (les jetons 24h+ sont dangereux en cas de vol) ; (3) accepter alg: none ou laisser le jeton choisir l’algorithme ; (4) stocker les JWT dans localStorage où le XSS peut les voler — préférez les cookies httpOnly avec SameSite=Lax ; (5) ne pas valider aud, acceptant des jetons émis pour des services sibling. Le pattern qui fonctionne bien : jetons d’accès de 5 à 15 minutes + jetons de rafraîchissement de longue durée révocables + session côté serveur opaque pour les opérations genuinement sensibles. Référence : RFC 8725 — Meilleures pratiques actuelles pour JSON Web Token.

Pourquoi les JWT ne sont pas chiffrés par défaut : un JWT ordinaire est signé mais pas confidentiel — quiconque possède le jeton peut décoder en base64 la charge utile et lire chaque claim, incluant l’email de l’utilisateur, ses rôles et toute donnée spécifique à l’application que l’émetteur a choisi d’incorporer. Cela prend les ingénieurs au dépourvu à répétition : mettre des DCP ou des identifiants d’utilisateurs internes dans un JWT en supposant que le jeton est une boîte noire est une fuite de données en attente. Pour la confidentialité, chiffrez la charge utile avec JWE (JSON Web Encryption, RFC 7516), qui produit un jeton à cinq segments avec un chiffrement approprié en plus de la signature. La plupart des systèmes de production gardent soit les DCP hors de la charge utile, soit utilisent des jetons de session opaques avec des lookups d’état côté serveur.

Jetons de rafraîchissement, expiration et le problème de révocation : la vérification sans état est la fonctionnalité phare de JWT et aussi sa plus grande vulnérabilité opérationnelle — une fois émis, un JWT ne peut pas être révoqué avant son expiration. L’atténuation standard est des jetons d’accès de courte durée (5 à 15 minutes) associés à des jetons de rafraîchissement de longue durée (jours à mois) révocables via une liste de refus côté serveur ; le client échange le jeton de rafraîchissement contre un nouveau jeton d’accès périodiquement. Les JWT de longue durée (24 heures et plus) sont un anti-pattern pour tout ce qui est sensible — un jeton volé est un laissez-passer gratuit jusqu’à l’expiration. Le décodeur JWT de Convertitive met en évidence le claim exp pour que vous puissiez voir rapidement si un jeton est trop longtemps valide. Référence : RFC 7519 — JSON Web Token.