Bonnes pratiques pour une implémentation sécurisée des JWT

La sécurité des JWT ne peut pas dépasser celle de leur implémentation. La spécification est flexible, et cette flexibilité crée des vulnérabilités. Suivez ces bonnes pratiques pour éviter les pièges courants qui ont entraîné des contournements de l’authentification dans des systèmes en production.

Spécifiez toujours explicitement l’algorithme attendu : jwt.decode(token, key, algorithms=["RS256"]). Ne lisez jamais l’algorithme dans l’en-tête du jeton pour sélectionner la clé de vérification ou le chemin de code. Cela empêche les attaques alg=none et les attaques de confusion de clés.

Jetons d’accès : 15 à 60 minutes. Jetons d’actualisation : 7 à 30 jours, stockés dans des cookies httpOnly (et non dans localStorage). À l’expiration, le client utilise le jeton d’actualisation pour obtenir un nouveau jeton d’accès auprès du serveur d’authentification, sans nouvelle authentification.

Validez aud (audience) pour vous assurer que le jeton a été émis pour votre service et non pour un autre. Validez iss (émetteur) par rapport à l’URL de votre serveur d’authentification. Sans ces vérifications, un jeton d’une autre application signé avec la même clé serait accepté.

Jetons d’accès en mémoire (variable JS) — effacés à la fermeture de l’onglet. Jetons d’actualisation dans des cookies httpOnly, Secure, SameSite=Strict — inaccessibles à JavaScript. Ne stockez jamais de JWT dans localStorage : XSS peut les dérober.

Les JWT sont sans état : aucune révocation n’est intégrée. Options : maintenir une liste de révocation (liste de blocage) vérifiée à chaque requête ; utiliser une expiration très courte ; utiliser des jetons opaques avec une consultation centralisée dans les contextes exigeant un haut niveau de sécurité.

Faites régulièrement pivoter les clés de signature. Publiez plusieurs clés dans JWKS avec des valeurs kid différentes. Pendant la rotation : émettez de nouveaux jetons avec le nouveau kid, gardez l’ancienne clé active jusqu’à l’expiration des anciens jetons, puis supprimez l’ancienne clé de JWKS.

Ne placez jamais de données sensibles (mots de passe, numéros de sécurité sociale, cartes bancaires) dans la charge utile du JWT : elle est encodée en base64url, et non chiffrée. Utilisez JWE (chiffrement JSON) si vous avez besoin de revendications chiffrées, ou conservez les données sensibles côté serveur.

Transmettez les JWT uniquement via HTTPS. Un JWT intercepté via HTTP permet de contourner entièrement l’authentification. Définissez l’attribut Secure sur les cookies. Utilisez HSTS pour empêcher la rétrogradation du protocole. Ne consignez jamais les chaînes JWT complètes dans les journaux du serveur.

Utilisez des bibliothèques bien entretenues : PyJWT 2+, python-jose, auth0/node-jsonwebtoken 9+, Nimbus JOSE + JWT (Java). Évitez d’implémenter la vérification des JWT à partir de zéro. Consultez régulièrement les bases de données CVE pour détecter les vulnérabilités des bibliothèques.

Testez tous les vecteurs d’attaque : soumettez un jeton alg=none, un jeton de confusion RS256→HS256, un jeton expiré, un jeton avec une mauvaise audience et une charge utile altérée. Utilisez jwt.io pour créer des jetons de test. Ajoutez des tests d’intégration qui vérifient que ces jetons sont rejetés avec le code 401.

Une utilisation sécurisée des JWT exige des algorithmes imposés, une courte durée de validité des jetons d’accès, le stockage des jetons d’actualisation dans des cookies httpOnly, la validation de l’audience et de l’émetteur, ainsi que la rotation des clés. Suite : schémas cryptographiques de partage de secrets.