4. Security Considerations

Clients MUST validate the iss parameter precisely as described in Section 2.4 and MUST NOT allow multiple authorization servers to use the same issuer identifier. In particular, when authorization server details can be manually configured in the client, the client MUST ensure that the accepted iss values are unique for each authorization server.

Les clients DOIVENT valider le paramètre iss précisément comme décrit dans la section 2.4 et NE DOIVENT PAS permettre à plusieurs serveurs d'autorisation d'utiliser le même identifiant d'émetteur. En particulier, lorsque les détails du serveur d'autorisation peuvent être configurés manuellement dans le client, le client DOIT s'assurer que les valeurs iss acceptées sont uniques pour chaque serveur d'autorisation.

The iss parameter enables a client to decide if an authorization server "expects" to be used in an OAuth flow together with a certain token endpoint and potentially other endpoints, like the userinfo endpoint [OIDC.Core]. When OAuth metadata is used, the iss parameter identifies the issuer and therefore the respective OAuth metadata document that points to the other endpoints. When OAuth metadata is not used, the client can use, for example, a statically configured expected iss value for each configured authorization server.

Le paramètre iss permet à un client de décider si un serveur d'autorisation "s'attend" à être utilisé dans un flux OAuth avec un certain point de terminaison de jeton et potentiellement d'autres points de terminaison, comme le point de terminaison d'informations utilisateur [OIDC.Core]. Lorsque les métadonnées OAuth sont utilisées, le paramètre iss identifie l'émetteur et donc le document de métadonnées OAuth respectif qui pointe vers les autres points de terminaison. Lorsque les métadonnées OAuth ne sont pas utilisées, le client peut utiliser, par exemple, une valeur iss attendue configurée statiquement pour chaque serveur d'autorisation configuré.

The issuer identifier contained in the authorization response is not cryptographically protected against tampering. In general, mechanisms such as JWTs (as specified in [JARM]) could be used to protect the integrity of the authorization response. However, in mix-up attacks, the client generally receives the authorization response from an uncompromised authorization server. If an attacker can tamper with this authorization response before it is received by the client, the attacker would also have direct access to the authorization code. The attacker does not need to execute a mix-up attack to steal the authorization code. Therefore, integrity protection for the authorization response is not necessary to defend against mix-up attacks.

L'identifiant de l'émetteur contenu dans la réponse d'autorisation n'est pas protégé cryptographiquement contre la falsification. En général, des mécanismes tels que les JWT (tels que spécifiés dans [JARM]) pourraient être utilisés pour protéger l'intégrité de la réponse d'autorisation. Cependant, dans les attaques par confusion, le client reçoit généralement la réponse d'autorisation d'un serveur d'autorisation non compromis. Si un attaquant peut falsifier cette réponse d'autorisation avant qu'elle ne soit reçue par le client, l'attaquant aurait également un accès direct au code d'autorisation. L'attaquant n'a pas besoin d'exécuter une attaque par confusion pour voler le code d'autorisation. Par conséquent, la protection de l'intégrité de la réponse d'autorisation n'est pas nécessaire pour se défendre contre les attaques par confusion.

There are also alternative countermeasures to mix-up attacks. When an authorization response already includes an authorization server's issuer identifier by other means and this identifier is checked as laid out in Section 2.4, the use and verification of the iss parameter is not necessary and MAY be omitted. For example, this is the case when OpenID Connect response types that return an ID Token from the authorization endpoint (e.g., response_type=code id_token) or [JARM] are used. However, if a client receives an authorization response that contains multiple issuer identifiers, the client MUST reject the response if these issuer identifiers do not match. The details of alternative countermeasures are outside of the scope of this specification.

Il existe également des contre-mesures alternatives aux attaques par confusion. Lorsqu'une réponse d'autorisation inclut déjà l'identifiant de l'émetteur d'un serveur d'autorisation par d'autres moyens et que cet identifiant est vérifié comme indiqué dans la section 2.4, l'utilisation et la vérification du paramètre iss ne sont pas nécessaires et PEUVENT être omises. Par exemple, c'est le cas lorsque les types de réponse OpenID Connect qui renvoient un jeton d'ID à partir du point de terminaison d'autorisation (par exemple, response_type=code id_token) ou [JARM] sont utilisés. Cependant, si un client reçoit une réponse d'autorisation contenant plusieurs identifiants d'émetteur, le client DOIT rejeter la réponse si ces identifiants d'émetteur ne correspondent pas. Les détails des contre-mesures alternatives sortent du cadre de cette spécification.

Mix-up attacks are only relevant to clients that interact with multiple authorization servers. However, clients interacting with only one authorization server might add support for a second authorization server in the future. By supporting multiple authorization servers, they become vulnerable to mix-up attacks and need to apply countermeasures.

Les attaques par confusion ne concernent que les clients qui interagissent avec plusieurs serveurs d'autorisation. Cependant, les clients interagissant avec un seul serveur d'autorisation pourraient ajouter la prise en charge d'un deuxième serveur d'autorisation à l'avenir. En prenant en charge plusieurs serveurs d'autorisation, ils deviennent vulnérables aux attaques par confusion et doivent appliquer des contre-mesures.