Résumé

  • Le 24 août 2026, l’IESG a approuvé la révision 10 de draft-ietf-oauth-rfc8725bis comme Best Current Practice. Au gel des preuves, le texte restait un Internet-Draft dans la file du RFC Editor ; sa publication doit rendre RFC 8725 obsolète et mettre RFC 7519 à jour.
  • La règle d’exploitation essentielle est l’exclusion mutuelle des profils de validation. Une signature correcte prouve l’intégrité sous une clé ; l’autorisation exige encore le bon type de jeton, le bon émetteur, la bonne audience, les bonnes assertions, les bons en-têtes et le bon usage.

Deux portes, une même clé

Un service reçoit des notifications de sécurité sous forme de Security Event Tokens. À quelques mètres logiques, une API accepte des jetons d’accès. Les deux services font confiance au même émetteur et consultent le même jeu de clés. Un jeton d’événement, parfaitement signé, est présenté à l’API. La bibliothèque JWT renvoie « succès » ; la porte s’ouvre.

La clé n’a pas été compromise. C’est la frontière qui a disparu.

Cette scène est un exercice de contrôle, pas le récit d’un incident réel. Elle illustre la confusion entre JWT : substituer à un usage un jeton émis pour un autre. L’attaquant n’a nul besoin de fabriquer une signature lorsqu’un récepteur transforme une preuve d’origine en permission universelle.

Le remède n’est donc pas un algorithme plus spectaculaire. Il consiste à définir, pour chaque famille de jetons, un ensemble fermé de conditions acceptables. Le récepteur d’événements et l’API doivent pouvoir refuser réciproquement leurs objets, même si l’encodage, l’émetteur ou certaines assertions se ressemblent.

Une approbation, pas encore un RFC

L’annonce officielle situe la décision au 24 août 2026 à 18 h 02 UTC. La révision 10 de « JSON Web Token Best Current Practices », issue du groupe OAuth, a été approuvée pour publication en tant que Best Current Practice.

Le 28 août, le Datatracker indiquait encore un Internet-Draft actif, daté du 21 août, mis à jour le 25 et expirant le 22 février 2027. Son état IESG était RFC Ed Queue. Le RFC Editor attendait une référence et signalait donc un blocage éditorial. IANA ne prévoyait aucune nouvelle action de registre, tout en laissant apparaître une procédure en cours.

Il faut maintenir cette chronologie. La décision de l’IESG modifie la référence normative, mais elle ne constitue ni un numéro RFC, ni une publication terminée, ni une preuve de déploiement. Une fois publié dans les termes annoncés, le texte remplacera RFC 8725 et modifiera la spécification JWT de base, RFC 7519.

« JWT valide » mélange quatre verdicts

Un JWT est un format d’assertions. Il peut être porté par un JWS signé, un JWE chiffré, une construction imbriquée ou, dans un contexte qui l’autorise expressément, une forme non sécurisée. La sérialisation compacte à points n’est pas interchangeable avec toutes les sérialisations JSON de JOSE.

Le récepteur doit poser quatre questions dans l’ordre :

  1. l’objet respecte-t-il exactement la sérialisation admise par ce point d’entrée ?
  2. la protection cryptographique est-elle valide avec un algorithme autorisé et la clé prévue ?
  3. l’objet appartient-il à la famille de jetons que ce service sait interpréter ?
  4. ses assertions autorisent-elles cette action, maintenant, pour cet émetteur et cette audience ?

Déchiffrer un JWE ne vérifie pas automatiquement la signature d’un JWT interne. Parser un objet compact n’établit pas la confiance. Vérifier un JWS ne donne pas à ses assertions une portée illimitée. Chaque étape produit une preuve locale, pas un laissez-passer pour l’étape suivante.

Le type doit fermer une catégorie

La révision recommande l’usage explicite de typ lorsque plusieurs familles risquent d’être confondues. Le type prévu pour les Security Event Tokens par RFC 8417 peut distinguer ces notifications. En revanche, la valeur générique JWT ne dit rien de leur contrat applicatif : elle ne fait que répéter la nature générale du conteneur.

Un type explicite ne suffit pas à lui seul. Le nouveau texte demande que les règles de validation de jetons différents soient mutuellement exclusives. Cette séparation peut reposer sur des types distincts, des assertions ou valeurs obligatoires différentes, des en-têtes protégés, des clés, des audiences ou des émetteurs séparés.

RFC 9068 définit ainsi un profil JWT pour les jetons d’accès OAuth, tandis que RFC 8417 encadre les événements de sécurité. Tous deux peuvent être authentiques sans être substituables. L’application doit sélectionner le droit applicable au jeton avant de transformer son contenu en décision.

La migration mérite une stratégie. Beaucoup de jetons anciens omettent typ; une obligation immédiate pourrait les casser. Une première étape compatible consiste à rejeter toute valeur présente qui contredit le type attendu, à mesurer les absences, puis à rendre le champ obligatoire lorsque les émetteurs ont été corrigés.

Émetteur, audience et sujet ont une portée

L’émetteur désigne l’autorité qui affirme. L’audience délimite les récepteurs auxquels l’affirmation est destinée. Le contrôle doit intervenir avant que les assertions n’influencent le routage, les droits ou les données.

Deux services d’une même entreprise ne forment pas nécessairement une même audience. Un jeton destiné au service A ne devient pas valable pour B parce qu’ils utilisent le même fournisseur d’identité. La mutualisation administrative ne supprime pas les mandats applicatifs.

Même sub n’a pas de signification universelle. Selon le profil, il peut désigner un utilisateur, une application cliente ou le sujet d’un événement de sécurité. Le nom du champ reste identique ; son sens vient du contrat de la famille de jetons.

Une clé ne choisit pas l’algorithme

Le récepteur doit fixer lui-même sa liste d’algorithmes admis. L’en-tête alg est une donnée à contrôler, pas une instruction qui autorise le jeton à choisir sa propre méthode de vérification. La recommandation lie en outre chaque clé à un seul algorithme, pour empêcher qu’un même matériau cryptographique soit réinterprété sous des règles incompatibles.

Les en-têtes de sélection de clés forment une autre surface. kid, jku ou x5u peuvent déclencher une recherche locale ou distante. Sans validation stricte, ils ouvrent des chemins d’injection ou de requêtes serveur vers des destinations arbitraires. Avant vérification, ils restent des entrées hostiles ; après vérification, l’émetteur ne doit pas pour autant disposer d’un client réseau sans limites.

Le texte révisé rassemble aussi des défenses moins visibles : seuils de calcul pour le chiffrement fondé sur mot de passe, limites de décompression des JWE et algorithmes entièrement spécifiés tels que ceux de RFC 9864. Ces mesures répondent aux ambiguïtés et à l’épuisement de ressources, pas seulement à la falsification.

La trace minimale d’une autorisation

Une preuve exploitable relie les octets reçus, la sérialisation admise, le point d’entrée, le profil attendu, les en-têtes protégés, l’algorithme, la clé résolue, le résultat cryptographique, le type, l’émetteur, l’audience, les assertions requises, la fenêtre temporelle, la décision et l’effet final.

Un journal réduit à « JWT valide » efface précisément la chaîne qu’un audit devra reconstruire. Il ne permet pas de savoir si un bon jeton a traversé la mauvaise frontière, si une audience a été ignorée ou si la validation a réellement conduit à une action.

La discipline du code en fonctionnement impose de tester le récepteur réel. Le standard énonce l’invariant minimal ; seule l’observation du refus et de l’absence d’effet prouve que l’application le respecte.

Sources