1. Introduction
The OAuth 2.0 Authorization Framework [RFC6749] allows clients to interact with multiple independent authorization servers under the control of separate entities. Some OAuth grant types utilize the resource owner's user agent to deliver the authorization server's response to the OAuth client. One example of this pattern is the authorization response of the authorization code grant.
Le cadre d'autorisation OAuth 2.0 [RFC6749] permet aux clients d'interagir avec plusieurs serveurs d'autorisation indépendants sous le contrôle d'entités distinctes. Certains types d'octroi OAuth utilisent l'agent utilisateur du propriétaire de la ressource pour transmettre la réponse du serveur d'autorisation au client OAuth. Un exemple de ce modèle est la réponse d'autorisation de l'octroi de code d'autorisation.
The authorization response as specified in Section 4.1.2 of [RFC6749] does not contain any information about the identity of the authorization server that issued the response. Therefore, clients receiving a response from the resource owner's user agent cannot be sure who initially issued the response and the secrets contained therein. The lack of certainty about the origin of the response enables a class of attacks called "mix-up attacks".
La réponse d'autorisation telle que spécifiée dans la section 4.1.2 de la [RFC6749] ne contient aucune information sur l'identité du serveur d'autorisation qui a émis la réponse. Par conséquent, les clients recevant une réponse de l'agent utilisateur du propriétaire de la ressource ne peuvent pas être sûrs de qui a initialement émis la réponse et les secrets qu'elle contient. Le manque de certitude quant à l'origine de la réponse permet une classe d'attaques appelées "attaques par confusion" (mix-up attacks).
Mix-up attacks are a potential threat to all OAuth clients that interact with multiple authorization servers. When at least one of these authorization servers is under an attacker's control, the attacker can launch a mix-up attack to acquire authorization codes or access tokens issued by any one of the other authorization servers. There are multiple ways in which an attacker can gain control over an authorization server supported by the client; for instance, an authorization server could become compromised, or the attacker could register their own authorization server, for example, using dynamic client registration [RFC7591].
Les attaques par confusion sont une menace potentielle pour tous les clients OAuth qui interagissent avec plusieurs serveurs d'autorisation. Lorsqu'au moins l'un de ces serveurs d'autorisation est sous le contrôle d'un attaquant, l'attaquant peut lancer une attaque par confusion pour acquérir des codes d'autorisation ou des jetons d'accès émis par l'un quelconque des autres serveurs d'autorisation. Il existe plusieurs façons pour un attaquant de prendre le contrôle d'un serveur d'autorisation pris en charge par le client ; par exemple, un serveur d'autorisation pourrait être compromis, ou l'attaquant pourrait enregistrer son propre serveur d'autorisation, par exemple, en utilisant l'enregistrement dynamique de client [RFC7591].
OAuth clients that interact with only one authorization server are not vulnerable to mix-up attacks. However, when such clients decide to add support for a second authorization server in the future, they become vulnerable and need to apply countermeasures to mix-up attacks.
Les clients OAuth qui interagissent avec un seul serveur d'autorisation ne sont pas vulnérables aux attaques par confusion. Cependant, lorsque ces clients décident d'ajouter la prise en charge d'un deuxième serveur d'autorisation à l'avenir, ils deviennent vulnérables et doivent appliquer des contre-mesures aux attaques par confusion.
Mix-up attacks aim to steal an authorization code or access token by tricking the client into sending the authorization code or access token to the attacker instead of the honest authorization or resource server. This marks a severe threat to the confidentiality and integrity of resources whose access is managed with OAuth. A detailed description and different variants of the mix-up attack class can be found in Section 4.4 of "OAuth 2.0 Security Best Current Practice" [OAUTH-SECURITY-TOPICS] as well as in the original research first highlighting this attack class, "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect" [arXiv.1508.04324] and "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].
Les attaques par confusion visent à voler un code d'autorisation ou un jeton d'accès en incitant le client à envoyer le code d'autorisation ou le jeton d'accès à l'attaquant au lieu du serveur d'autorisation ou de ressource honnête. Cela constitue une menace grave pour la confidentialité et l'intégrité des ressources dont l'accès est géré avec OAuth. Une description détaillée et différentes variantes de la classe d'attaque par confusion peuvent être trouvées dans la section 4.4 des "Bonnes pratiques de sécurité actuelles OAuth 2.0" [OAUTH-SECURITY-TOPICS] ainsi que dans la recherche originale mettant en évidence cette classe d'attaque, "Sur la sécurité des protocoles modernes d'authentification unique : Vulnérabilités de second ordre dans OpenID Connect" [arXiv.1508.04324] et "Une analyse formelle complète de la sécurité d'OAuth 2.0" [arXiv.1601.01229].
This document defines a new parameter in the authorization response called iss. The iss parameter allows the authorization server to include its identity in the authorization response explicitly. The client can compare the value of the iss parameter to the issuer identifier of the authorization server (e.g., retrieved from its metadata) it believes it is interacting with. The iss parameter gives the client certainty about the authorization server's identity and enables it to send credentials such as authorization codes and access tokens only to the intended recipients.
Ce document définit un nouveau paramètre dans la réponse d'autorisation appelé iss. Le paramètre iss permet au serveur d'autorisation d'inclure explicitement son identité dans la réponse d'autorisation. Le client peut comparer la valeur du paramètre iss à l'identifiant de l'émetteur du serveur d'autorisation (par exemple, récupéré de ses métadonnées) avec lequel il pense interagir. Le paramètre iss donne au client une certitude sur l'identité du serveur d'autorisation et lui permet d'envoyer des informations d'identification telles que des codes d'autorisation et des jetons d'accès uniquement aux destinataires prévus.
The effectiveness of the iss parameter against mix-up attacks was analyzed and formally proven in "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].
L'efficacité du paramètre iss contre les attaques par confusion a été analysée et formellement prouvée dans "Une analyse formelle complète de la sécurité d'OAuth 2.0" [arXiv.1601.01229].
1.1. Conventions and Terminology
1.1. Conventions et terminologie
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
This specification uses the terms "access token", "authorization code", "authorization code grant", "authorization server", "resource server", "authorization response", "grant type", and "client" defined by the OAuth 2.0 Authorization Framework [RFC6749]. The term "issuer identifier" is defined by OAuth 2.0 Authorization Server Metadata [RFC8414].
Cette spécification utilise les termes "jeton d'accès", "code d'autorisation", "octroi de code d'autorisation", "serveur d'autorisation", "serveur de ressources", "réponse d'autorisation", "type d'octroi" et "client" définis par le cadre d'autorisation OAuth 2.0 [RFC6749]. Le terme "identifiant de l'émetteur" est défini par les métadonnées du serveur d'autorisation OAuth 2.0 [RFC8414].