JWS

JWS (JSON Web Signature, RFC 7515) est le cadre de signature cryptographique sur lequel JWT est construit. Un JWS comporte trois parties jointes par des points : en-tête.charge utile.signature, chaque segment encodé en base64url. L’en-tête est du JSON déclarant l’algorithme ; la charge utile peut être n’importe quels octets (typiquement mais pas nécessairement du JSON) ; la signature est calculée sur l’en-tête et la charge utile joints par un point en utilisant l’algorithme déclaré.

La relation JWT : tout JWT est un JWS dont la charge utile doit être un objet JSON de claims. Mais JWS lui-même est plus général — la charge utile peut être du binaire brut, un document XML, ou toute autre chaîne d’octets. Quand vous voyez un jeton à trois parties séparées par des points dont le segment central ne décode pas en JSON en base64, c’est un JWS, pas un JWT.

Algorithmes courants : HS256 (HMAC-SHA256, clé symétrique), RS256 (RSA-SHA256, asymétrique), ES256 (ECDSA-P256-SHA256, asymétrique). L’algorithme dangereux none signifie “pas de signature” — légal selon la spec mais à toujours rejeter côté serveur. Les vérificateurs de production doivent également vérifier explicitement que l’algorithme déclaré dans l’en-tête correspond à l’algorithme attendu pour la clé.

JWS a deux sérialisations : compacte (le format à points séparés que JWT utilise) et JSON (une enveloppe JSON enveloppant les trois mêmes parties, supportant plusieurs signatures). La forme compacte est ce qu’utilisent presque toutes les API ; la forme JSON est rare en dehors de protocoles spécifiques.

Exemple concret

Prenons le JWS eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.4Adcj3UFYzPUVaHwte4eBI6vsjOvpz0yiwIM0F7sjuk. Décodez l’en-tête (premier segment) : {"alg":"HS256"} — signature HMAC-SHA256. Décodez la charge utile (deuxième segment) : {"sub":"user_123"}. La signature (troisième segment) est le HMAC-SHA256 de eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9 en utilisant la clé secrète partagée. Le vérificateur reconstruit le HMAC et compare en utilisant une comparaison à temps constant ; discordance → rejet. Comparez maintenant avec RS256 : même structure, mais la signature est RSA-SHA256, l’émetteur signe avec une clé privée et les vérificateurs contrôlent avec la clé publique. Les octets du jeton sont plus longs (les signatures RSA font ~342 caractères base64 pour une clé 2048 bits contre 43 pour HMAC-SHA256) mais la sémantique de validation est identique du point de vue de l’appelant.

Quand et pourquoi c’est important

JWS importe chaque fois qu’un service émet, transmet ou accepte un JWT — ce qui en 2026 concerne la plupart des API. Les erreurs qui ont produit des CVE à répétition au cours de la dernière décennie : (1) ne pas valider du tout la signature, traitant la charge utile comme fiable simplement parce qu’elle se parse en JSON ; (2) accepter alg: none, ce qui supprime complètement la signature ; (3) accepter n’importe quel algorithme déclaré par le jeton, permettant l’attaque de confusion HS256-avec-clé-publique-RSA ; (4) ne pas valider exp, permettant le rejeu de jetons expirés depuis longtemps ; (5) ne pas valider iss et aud, acceptant des jetons émis pour des services entièrement différents. La base de sécurité défensive : épinglez l’algorithme attendu dans l’appel de vérification, récupérez la clé de vérification depuis une source fiable (typiquement une URL JWKS mise en liste blanche au moment de la configuration, pas le propre jku du jeton), et validez exp, iss et aud comme vérifications post-signature séparées. Référence : RFC 8725 — Meilleures pratiques actuelles pour JWT.

Pourquoi l’attaque par confusion d’algorithme apparaît encore dans les CVE : une longue famille de vulnérabilités JWS implique un serveur qui demande à la bibliothèque JWT “ce jeton est-il valide ?” et laisse la bibliothèque choisir l’algorithme de vérification depuis le propre en-tête du jeton. Un attaquant connaissant la clé RSA publique du serveur (qui est, par définition, publique) peut fabriquer un jeton signé avec HMAC-SHA256 en utilisant les octets de la clé publique RSA comme secret HMAC, mettre alg: HS256 dans l’en-tête, et de nombreuses bibliothèques le vérifieront. L’atténuation est de verrouiller la vérification à l’algorithme attendu — passez-le comme argument explicite à l’appel de vérification plutôt que de laisser le jeton le nommer. La divulgation de 2015 de ceci contre plusieurs bibliothèques majeures (jsonwebtoken de Node, pyjwt de Python, plusieurs implémentations Java) est l’histoire édifiante de référence.

JWS détaché — quand la charge utile est trop volumineuse pour être incorporée : RFC 7797 définit un mode de “charge utile détachée” où le segment central est vide et la charge utile est transmise hors bande (ex. comme le corps HTTP, tandis que le JWS se trouve dans un en-tête). C’est ainsi que certaines API financières signent de grands corps de requête sans ré-encoder en base64 des mégaoctets de JSON. La signature est encore calculée sur les octets de la charge utile originale ; seul le format de transmission change. Référence : RFC 7515 — JSON Web Signature.