HS256 ou RS256 : JWT symétriques ou asymétriques

La signature des JWT utilise des algorithmes symétriques (HMAC) ou asymétriques (RSA, ECDSA). HS256 = HMAC-SHA256. RS256 = RSA-PKCS1v1.5-SHA256. ES256 = ECDSA-P256-SHA256. Ce choix influe sur la distribution des clés et le modèle de confiance.

HS256 utilise une seule clé secrète partagée pour la signature et la vérification. L’émetteur et chaque vérificateur doivent posséder le même secret. Cette solution est simple à mettre en œuvre, mais elle exige de distribuer la clé de manière sécurisée à tous les vérificateurs.

HS256 convient lorsque l’émetteur et le vérificateur sont le même service (par exemple, une API monolithique qui signe et vérifie ses propres jetons). N’utilisez jamais HS256 si plusieurs services indépendants doivent vérifier les jetons : ils auraient tous besoin du secret.

RS256 utilise une clé privée pour signer et une clé publique pour vérifier. Seul le serveur d’authentification détient la clé privée. Tous les serveurs de ressources récupèrent la clé publique depuis le point de terminaison JWKS et vérifient localement, sans partage de secret.

RS256 convient parfaitement aux architectures de microservices : le fournisseur d’identité signe les jetons et chaque service en aval les vérifie avec la clé publique sans contacter l’IDP à chaque requête. La solution s’adapte horizontalement sans risque lié à la distribution des clés.

ES256 utilise ECDSA sur P-256. La signature occupe 64 octets, contre 256 octets pour RS256 avec une clé de 2048 bits. Sa vérification est environ 10 fois plus rapide que celle de RS256. Il est préférable lorsque la bande passante ou la vitesse de vérification est essentielle (API mobiles, IoT).

Pour RS256/ES256, faites pivoter les clés en publiant une nouvelle clé (nouveau kid) dans JWKS, en signant les nouveaux jetons avec la nouvelle clé, en laissant s’écouler une période de grâce pour que les anciens jetons expirent, puis en supprimant l’ancienne clé. La rotation HMAC nécessite de redistribuer le nouveau secret.

Vérification HS256 : environ 1 µs. Vérification RS256 : environ 100 µs (2048 bits). Vérification ES256 : environ 50 µs (P-256). HS256 est le plus rapide, mais exige le partage d’un secret. ES256 offre le meilleur équilibre entre sécurité et performances pour les systèmes distribués.

Une vulnérabilité critique : si le vérificateur fait aveuglément confiance à l’en-tête alg, un attaquant peut remplacer alg par HS256 et signer le jeton avec la clé publique du serveur (qui est publique) comme secret HMAC. Correction : ne faites jamais confiance à l’en-tête alg.

Décision : service unique → HS256. Services multiples ou microservices → RS256 ou ES256. Application mobile à fort volume → ES256. En cas de doute, utilisez ES256 (P-256) ou RS256 avec des clés d’au moins 2048 bits. N’utilisez jamais RS512 sur les chemins sensibles aux performances.

Utilisez PyJWT (Python), jose (Node.js) ou auth0/java-jwt. Spécifiez toujours explicitement l’algorithme attendu dans l’appel de vérification : jwt.decode(token, secret, algorithms=["HS256"]). Ne transmettez jamais algorithms=None et n’omet­tez jamais ce paramètre.

Pourquoi RS256 est-il préféré à HS256 dans les architectures de microservices ?

HS256 est symétrique (secret partagé), tandis que RS256/ES256 sont asymétriques (signature privée, vérification publique). Utilisez des algorithmes asymétriques pour les systèmes impliquant plusieurs parties. Suite : exploiter les vulnérabilités des JWT.