JWT Security

Définition

JWT (JSON Web Token) Security couvre les pratiques de sécurisation de l'utilisation des JSON Web Tokens, un standard ouvert (RFC 7519) largement utilisé pour l'authentification et l'autorisation dans les APIs REST et les architectures microservices. Bien que le format JWT soit bien défini, son implémentation présente de nombreux pièges de sécurité qui ont conduit à des vulnérabilités critiques dans des centaines d'applications. Un JWT est composé de trois parties encodées en Base64URL séparées par des points : le Header (algorithme de signature et type), le Payload (claims : identité de l'utilisateur, rôles, expiration), et la Signature. La validité d'un JWT repose sur la vérification de sa signature par le serveur, garantissant que le token n'a pas été modifié depuis son émission. Les vulnérabilités classiques des implémentations JWT sont bien documentées. L'attaque "algorithm confusion" (CVE-2015-9235) exploite la possibilité de spécifier "alg: none" dans le header JWT, contournant la vérification de signature sur des bibliothèques vulnérables. L'attaque RS256 to HS256 (algorithm confusion) trompe un serveur utilisant RS256 en lui soumettant un JWT signé avec HS256 en utilisant la clé publique RSA comme secret HMAC. La faiblesse des secrets HMAC (HS256 avec des secrets courts ou prévisibles) permet des attaques par force brute (hashcat peut casser des secrets JWT HS256 faibles en quelques heures). D'autres vulnérabilités incluent : l'absence de vérification de l'expiration (claim "exp"), l'absence de vérification de l'audience (claim "aud") permettant la réutilisation de tokens entre services, les claims sensibles en clair dans le payload (les JWTs sont encodés, pas chiffrés — n'importe qui peut lire le payload sans la clé), la mauvaise gestion de la révocation (les JWTs sont stateless, il n'est pas possible de les invalider sans mécanisme supplémentaire comme une blacklist ou un versioning). Les bonnes pratiques JWT incluent : utiliser RS256 ou ES256 (asymétriques) plutôt que HS256 pour les architectures multi-services, des secrets HS256 d'au moins 256 bits générés aléatoirement, des durées d'expiration courtes (15 minutes à 1 heure), la vérification de tous les claims (exp, iss, aud, nbf), et un mécanisme de rotation/révocation via des refresh tokens.