Résumé

  • La RFC 9207 fournit au client OAuth un reçu très précis : l’émetteur de la réponse d’autorisation doit être identique à celui qui a été enregistré pour cette demande. En cas d’écart, le flux s’arrête avant l’envoi du code au mauvais endpoint.
  • Le paramètre iss identifie le contexte du serveur d’autorisation. Il n’authentifie pas l’utilisateur, ne valide pas le code, ne garantit pas l’émission d’un jeton et ne prouve aucune décision du serveur de ressources.
  • L’exploitation sûre doit donc relier des traces distinctes : état de la demande, émetteur attendu, métadonnées, émetteur reçu, comparaison, échange du code, validation du jeton, décision sur la ressource et récupération.

Le callback dangereux n’a rien d’exotique.

Le navigateur revient sur une URI de redirection enregistrée. La valeur state correspond à celle créée par le client. La réponse transporte un code produit par un serveur d’autorisation honnête. Aucun mot de passe n’a été volé et personne n’a fabriqué le code. Pourtant, si le client travaille avec plusieurs serveurs d’autorisation, il peut commettre une erreur décisive : envoyer ce code honnête au token endpoint contrôlé par l’attaquant.

Deux éléments vraisemblables ont été confondus. Le premier indique le serveur choisi quand le flux a commencé. Le second est une réponse revenue par le navigateur de l’utilisateur. Dans la réponse définie à l’origine par OAuth 2.0, rien ne disait explicitement quel serveur l’avait créée. Si le client laisse une route de callback générique ou des métadonnées hostiles effacer cette distinction, un code valide peut passer sous le contrôle d’un autre opérateur.

La RFC 9207 répare cet espace avec un mécanisme volontairement petit. OAuth 2.0 Authorization Server Issuer Identification, publiée en mars 2022 comme document IETF sur la voie de normalisation, est l’œuvre collective de Karsten Meyer zu Selhausen et Daniel Fett. Elle définit iss dans la réponse d’autorisation. Le serveur compatible place son identifiant d’émetteur dans les réponses de succès comme dans les réponses d’erreur. Le client compare ensuite cette valeur avec l’émetteur associé au serveur auquel il avait adressé la demande.

Si les deux chaînes ne correspondent pas, le client rejette la réponse et ne poursuit pas l’octroi.

C’est la totalité du pouvoir du champ — et la raison de son importance.

Le callback ne disait pas qui répondait

OAuth sépare intentionnellement les rôles. Le propriétaire de la ressource utilise un agent utilisateur. Un client demande un octroi à un serveur d’autorisation. Il présente ensuite cet octroi à un token endpoint. Enfin, le jeton d’accès sert auprès d’un serveur de ressources. Cette composition permet à des services indépendants de travailler ensemble, mais elle crée des décisions de routage que l’arrivée du navigateur ne suffit pas à sécuriser.

La RFC 6749 mettait dans la réponse un code et, lorsque la demande en contenait une, la même valeur state. Cet état est indispensable : il lie la réponse à l’état authentifié de l’agent utilisateur et combat notamment la falsification de requête intersite. Il ne répond toutefois pas à l’autre question : quel serveur d’autorisation a émis cette réponse ?

Avec un seul serveur, la différence peut rester invisible, puisqu’il n’existe pas d’autre ensemble d’endpoints. Dès qu’un second serveur entre dans la configuration, le client doit mémoriser plus que l’existence d’un flux en attente. Il doit savoir quel émetteur possède ce flux. La RFC 9700, pratique actuelle recommandée pour la sécurité OAuth, exige qu’un client multi-émetteurs prévienne les attaques par confusion et relie l’émetteur attendu à chaque demande.

Le parcours public de Daniel Fett rend cette question intelligible sans transformer un texte collectif en récit héroïque. Son site le présente comme consultant en sécurité spécialisé dans l’identité et les protocoles web, actif sur OAuth et OpenID Connect. Son dossier IETF recensait quatre RFC, dont la RFC 9207, lors de la vérification de septembre 2026. Cela situe la continuité de ses travaux. Cela ne lui attribue ni l’invention exclusive du paramètre ni le contrôle d’un client déployé.

Un émetteur désigne un ensemble d’endpoints

L’identifiant d’émetteur n’est pas un simple nom d’affichage. Dans la RFC 8414, il s’agit d’une URL HTTPS sans requête ni fragment. Elle ancre un document de métadonnées qui peut désigner l’endpoint d’autorisation, le token endpoint, l’emplacement des clés et d’autres capacités. Un même hôte peut porter plusieurs émetteurs distingués par leur chemin.

Cet ensemble est l’objet opérationnel à protéger. Un client peut afficher à l’utilisateur une page d’autorisation honnête tout en ayant reçu une configuration où le token endpoint appartient à l’attaquant. La RFC 9700 prévient que mémoriser uniquement l’URL de l’endpoint d’autorisation ne suffit pas : une configuration malveillante peut emprunter l’adresse honnête pour l’autorisation et déclarer sa propre adresse pour l’échange du code. L’émetteur doit identifier de façon stable tout l’ensemble attendu.

La RFC 9207 rattache la réponse transportée par le navigateur à cet ensemble. Quand les métadonnées sont utilisées, le iss de la réponse doit être identique à l’issuer des métadonnées, lesquelles annoncent la prise en charge grâce à authorization_response_iss_parameter_supported. Le client extrait la valeur, la décode conformément à l’encodage de formulaire puis effectue une comparaison simple de chaînes avec la valeur attendue.

Aucune ressemblance approximative n’est permise. Une différence de chemin, une barre oblique inattendue ou un autre émetteur sur le même hôte ne sont pas « suffisamment proches ». Ce n’est pas une comparaison destinée à un lecteur humain : c’est une décision de routage déterministe.

La surface de décision reste locale. Le serveur déclare son identité. Les métadonnées décrivent les endpoints. Le client enregistre l’émetteur choisi, conserve l’état de prise en charge du serveur et décide si la réponse est admissible. Aucune autorité mondiale n’exécute cette comparaison ; chaque client demeure responsable de sa configuration et de son abandon.

Une égalité permet de continuer, pas de conclure

Le détournement intellectuel le plus facile consiste à donner trop de sens au résultat.

Une égalité d’émetteur n’authentifie pas le propriétaire de la ressource. Le serveur peut encore demander une connexion ou renvoyer une erreur. Elle ne prouve pas que l’utilisateur a compris l’étendue demandée. Cette question relève de l’interaction d’autorisation et de la politique applicative.

L’égalité ne valide pas non plus le code. Après sélection du bon token endpoint, celui-ci doit vérifier le code, l’identité du client si elle est requise, l’URI de redirection et les autres conditions de l’octroi. Le code peut être expiré, rejoué ou lié à un autre client.

Enfin, iss ne prouve pas qu’un jeton a été émis. Il ne décrit ni son type, ni son audience, ni ses portées, ni sa durée, ni sa liaison à un expéditeur, ni sa révocation. Le serveur de ressources conserve sa propre décision. Même un jeton valide et correctement limité ne garantit pas que l’action applicative a réussi ou que l’utilisateur en a vu le résultat.

Il faut donc conserver une chaîne de reçus : création de la demande et émetteur attendu ; retour de la réponse ; valeur iss reçue ; décision de comparaison ; sélection des endpoints à partir de métadonnées validées ; acceptation ou refus du code ; validation et application du jeton ; résultat observé et capacité de récupération.

La RFC 9207 porte sur la comparaison. Appeler cette comparaison « succès OAuth » efface toutes les décisions qui suivent.

Le paramètre n’est pas une signature

Dans une réponse ordinaire, iss n’est pas protégé cryptographiquement. La RFC le dit explicitement. Ce n’est contradictoire que si l’on présente le champ comme un certificat universel d’authenticité.

Le modèle de menace est plus étroit. Dans une attaque par confusion, le client reçoit une réponse créée par un serveur non compromis, mais se trompe sur l’ensemble d’endpoints auquel envoyer le code. Un attaquant capable de modifier cette réponse avant sa réception peut déjà lire le code ; il n’a pas besoin du détour de la confusion. Le champ empêche l’erreur de routage dans ce modèle, pas toute altération imaginable.

Un système qui exige une réponse protégée en intégrité peut employer d’autres mécanismes. JARM transporte les paramètres dans un JWT signé. Certains flux OpenID Connect renvoient un ID Token à l’endpoint d’autorisation et peuvent porter un émetteur, à condition de le valider correctement. Si plusieurs identifiants d’émetteur présents dans la même réponse ne concordent pas, le client doit rejeter la réponse.

On retrouve ici le principe de spécification initiale minimale : ajouter le signal partagé le plus petit qui révèle l’ambiguïté, sans imposer un seul futur à tous les opérateurs. Les enveloppes plus fortes, les politiques de compatibilité et les plans de migration restent des choix locaux. La RFC 9700 autorise aussi des URI de redirection distinctes par émetteur, si le client les contrôle effectivement.

La compatibilité historique doit avoir un propriétaire

Tous les serveurs ne sont pas mis à niveau ensemble. La RFC 9207 conserve donc un état de prise en charge au lieu de feindre une adoption universelle.

Lorsqu’un client sait qu’un serveur prend iss en charge, l’absence de ce paramètre doit entraîner un rejet. Si le serveur n’est pas compatible, le client peut accepter une réponse sans iss ou refuser complètement ce serveur. La politique locale tranche. Une valeur reçue d’un serveur qui n’a pas annoncé sa prise en charge mérite aussi une décision explicite, car elle peut signaler une configuration incohérente.

Cette souplesse situe la responsabilité. Un client multi-émetteurs doit inventorier chaque émetteur, ses métadonnées, son indicateur de prise en charge, la date et la source de cette connaissance, l’éventuelle exception historique et son responsable. Sans date de sortie, la compatibilité devient un itinéraire permanent autour de la défense.

L’ajout d’un second fournisseur change également le risque. Un client à émetteur unique peut ne pas avoir besoin de la défense aujourd’hui. Dès le deuxième émetteur, l’ancienne hypothèse expire. L’expansion produit crée donc une migration de sécurité qui doit précéder la mise en service commerciale.

Le test que l’exploitation peut réellement exécuter

Lire les métadonnées une fois ne prouve pas la conformité. Un test utile suit la décision depuis la création de la demande.

Il enregistre l’identifiant de la demande, la liaison à l’agent utilisateur, l’émetteur sélectionné, la version des métadonnées, les endpoints, l’indicateur de prise en charge et l’URI de redirection. Au retour, il note la présence de iss, sa valeur décodée, la valeur attendue, le résultat de la comparaison et la suppression effective de l’échange du code en cas d’écart. Il couvre les succès, les erreurs, les valeurs absentes ou multiples, les émetteurs inconnus et les chemins distincts sur un même hôte.

Le test le plus important est négatif. Après une différence, aucune requête contenant le code, un secret du client ou un jeton ne doit atteindre l’endpoint inattendu. Les traces du client et celles d’endpoints de test contrôlés doivent concorder. Un message d’erreur visible accompagné d’une requête réseau sortante n’est pas un reçu de défense.

L’analyse d’incident garde enfin les couches séparées. Un écart d’émetteur prouve l’échec d’une comparaison, pas nécessairement une compromission. Un refus du token endpoint prouve le rejet d’un octroi, pas l'origine hostile de la réponse. Un refus de ressource ne démontre pas rétroactivement que la liaison d’émetteur a fonctionné.

La réussite du champ tient à sa modestie : il rend une ambiguïté impossible à ignorer avant le déplacement d’un secret. Il ne remplace aucune des décisions que le client, le serveur d’autorisation, le token endpoint et le serveur de ressources doivent encore prendre.

Sources