En-tête (JWT/JWS)

L’en-tête d’un JWT (ou JWS) est le premier segment séparé par des points, un objet JSON encodé en base64url qui décrit les propriétés de signature du token. Décodez-le et vous obtenez un petit objet JSON contenant généralement 2 à 5 champs.

Champs d’en-tête standard (RFC 7515 §4) :

• alg — algorithme. Obligatoire. Par exemple HS256, RS256, ES256, ou none.
• typ — type. Conventionnellement "JWT" lorsque le payload est un ensemble de revendications JWT.
• kid — identifiant de clé. Permet au récepteur de choisir la bonne clé dans un ensemble de clés lorsque l’émetteur fait pivoter les clés.
• jwk / jku — clé Web JSON intégrée ou URL vers une clé. Moins courant ; sensible sur le plan de la sécurité si utilisé.
• cty — type de contenu. Utilisé lorsque le payload est une structure JOSE imbriquée (par exemple un JWE dans un JWS).

Exemple concret. Un en-tête se décodant en :

{ "alg": "RS256", "typ": "JWT", "kid": "2024-q1-key" }

déclare que le token est signé avec RS256 (RSA + SHA-256), est un JWT (donc le payload est un ensemble de revendications), et a été signé avec la clé identifiée par 2024-q1-key dans le répertoire de clés de l’émetteur.

Note de sécurité critique : ne faites jamais confiance au champ alg seul. Vérifiez que l’algorithme correspond à ce pour quoi votre clé est appropriée. L’attaque par confusion d’algorithme fonctionne en passant un token signé avec HS256 (HMAC) en utilisant votre clé publique RSA comme secret HMAC — si votre vérificateur fait aveuglément confiance à alg, il accepte la falsification.

L’encodage base64url compact de l’en-tête le rend inspectable par l’homme : coller le premier segment séparé par des points de n’importe quel JWT dans un décodeur base64url révèle l’algorithme et la référence de clé en quelques secondes. C’est le point d’entrée de chaque session de débogage JWT — si l’en-tête se décode en données corrompues, le token est malformé ; s’il se décode en un objet JSON que vous ne reconnaissez pas, l’émetteur a changé quelque chose.

Quand et pourquoi cela compte

L’en-tête JWT est important chaque fois qu’un service vérifie un token. La chaîne CVE classique : un vérificateur accepte le champ alg à sa valeur nominale et laisse passer un token spécifiant "alg": "none" sans vérification de signature du tout. Ce bug a été livré en production dans des bibliothèques aussi récemment qu’en 2015 (CVE-2015-9235, affectant node-jsonwebtoken d’Auth0). La défense est d’imposer, dans l’appel de vérification, l’algorithme exact que la bibliothèque doit accepter — par exemple jwt.verify(token, key, { algorithms: ['RS256'] }) — et de ne jamais faire confiance à l’en-tête pour choisir l’algorithme. Une deuxième classe de bugs, l’attaque par confusion d’algorithme, exploite les bibliothèques qui sélectionnent automatiquement HMAC vs RSA selon l’en-tête : l’attaquant remet au vérificateur un token revendiquant HS256 mais le signe avec la clé publique RSA (publiée) utilisée comme secret HMAC. Le vérificateur valide contre la clé publique et accepte la falsification. Les deux bugs sont des problèmes de confiance dans l’en-tête. Pour les nouvelles intégrations JWT, auditez l’appel de vérification et vérifiez qu’il épingle l’algorithme. Référence : OWASP — Aide-mémoire JSON Web Token.

Le champ kid dans la rotation de clés en production : dans tout système réel qui émet des tokens à grande échelle, la clé de signature doit être renouvelée périodiquement — tous les 90 jours est une politique courante. Le champ kid permet à l’émetteur de publier plusieurs clés simultanément (anciennes clés pour les tokens en cours, nouvelles clés pour les émissions récentes) et le vérificateur choisit la bonne à partir d’un endpoint JWKS. Le modèle de rotation standard : annoncer la nouvelle clé dans le JWKS tout en continuant à signer avec l’ancienne clé, attendre une durée de vie de token, basculer l’émission vers la nouvelle clé, attendre une autre durée de vie, puis supprimer l’ancienne clé du JWKS. Le champ kid est ce qui rend cela élégant — sans lui, la rotation de clés nécessite un basculement synchronisé.

À quoi ressemble le vecteur d’attaque jku / x5u : certaines implémentations permettent à l’en-tête de pointer vers une URL arbitraire où la clé de vérification est supposément stockée. Un attaquant qui définit jku vers une URL qu’il contrôle peut présenter n’importe quelle clé et le vérificateur l’utilisera. Les directives modernes (RFC 8725, meilleures pratiques JOSE) consistent soit à rejeter entièrement jku/x5u, soit à imposer une liste d’URL de confiance autorisées. Les nouvelles intégrations JWT ne devraient pas s’appuyer sur l’emplacement de clé contrôlé par l’en-tête. Référence : RFC 8725 — Meilleures pratiques actuelles JSON Web Token.