Aller au contenu principal

2. Response Parameter iss

In authorization responses to the client, including error responses, an authorization server supporting this specification MUST indicate its identity by including the iss parameter in the response.

Dans les réponses d'autorisation au client, y compris les réponses d'erreur, un serveur d'autorisation prenant en charge cette spécification DOIT indiquer son identité en incluant le paramètre iss dans la réponse.

The iss parameter value is the issuer identifier of the authorization server that created the authorization response, as defined in [RFC8414]. Its value MUST be a URL that uses the "https" scheme without any query or fragment components.

La valeur du paramètre iss est l'identifiant de l'émetteur du serveur d'autorisation qui a créé la réponse d'autorisation, tel que défini dans [RFC8414]. Sa valeur DOIT être une URL qui utilise le schéma "https" sans aucun composant de requête ou de fragment.

2.1. Example Authorization Response

2.1. Exemple de réponse d'autorisation

The following example shows an authorization response from the authorization server whose issuer identifier is https://honest.as.example (extra line breaks and indentation are for display purposes only):

L'exemple suivant montre une réponse d'autorisation du serveur d'autorisation dont l'identifiant de l'émetteur est https://honest.as.example (les sauts de ligne et l'indentation supplémentaires sont uniquement à des fins d'affichage) :

HTTP/1.1 302 Found
Location: https://client.example/cb?
code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58
&state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
&iss=https%3A%2F%2Fhonest.as.example

2.2. Example Error Response

2.2. Exemple de réponse d'erreur

The following example shows an error response from the same authorization server (extra line breaks and indentation are for display purposes only):

L'exemple suivant montre une réponse d'erreur du même serveur d'autorisation (les sauts de ligne et l'indentation supplémentaires sont uniquement à des fins d'affichage) :

HTTP/1.1 302 Found
Location: https://client.example/cb?
error=access_denied
&state=N2JjNGJhY2JiZjRhYzA3MGJkMzNmMDE5OWJhZmJhZjA
&iss=https%3A%2F%2Fhonest.as.example

2.3. Providing the Issuer Identifier

2.3. Fournir l'identifiant de l'émetteur

Authorization servers supporting this specification MUST provide their issuer identifier to enable clients to validate the iss parameter effectively.

Les serveurs d'autorisation prenant en charge cette spécification DOIVENT fournir leur identifiant d'émetteur pour permettre aux clients de valider efficacement le paramètre iss.

For authorization servers publishing metadata according to [RFC8414], the following rules apply:

Pour les serveurs d'autorisation publiant des métadonnées selon [RFC8414], les règles suivantes s'appliquent :

  • The issuer identifier included in the server's metadata value issuer MUST be identical to the iss parameter's value.

  • L'identifiant de l'émetteur inclus dans la valeur de métadonnées du serveur issuer DOIT être identique à la valeur du paramètre iss.

  • The server MUST indicate its support for the iss parameter by setting the metadata parameter authorization_response_iss_parameter_supported, defined in Section 3, to true.

  • Le serveur DOIT indiquer sa prise en charge du paramètre iss en définissant le paramètre de métadonnées authorization_response_iss_parameter_supported, défini dans la section 3, sur true.

Authorization servers MAY additionally provide the issuer identifier to clients by any other mechanism, which is outside of the scope of this specification.

Les serveurs d'autorisation PEUVENT en outre fournir l'identifiant de l'émetteur aux clients par tout autre mécanisme, ce qui sort du cadre de cette spécification.

2.4. Validating the Issuer Identifier

2.4. Validation de l'identifiant de l'émetteur

Clients that support this specification MUST extract the value of the iss parameter from authorization responses they receive if the parameter is present. Clients MUST then decode the value from its "application/x-www-form-urlencoded" form according to Appendix B of [RFC6749] and compare the result to the issuer identifier of the authorization server where the authorization request was sent to. This comparison MUST use simple string comparison as defined in Section 6.2.1 of [RFC3986]. If the value does not match the expected issuer identifier, clients MUST reject the authorization response and MUST NOT proceed with the authorization grant. For error responses, clients MUST NOT assume that the error originates from the intended authorization server.

Les clients qui prennent en charge cette spécification DOIVENT extraire la valeur du paramètre iss des réponses d'autorisation qu'ils reçoivent si le paramètre est présent. Les clients DOIVENT ensuite décoder la valeur de sa forme "application/x-www-form-urlencoded" selon l'annexe B de [RFC6749] et comparer le résultat à l'identifiant de l'émetteur du serveur d'autorisation où la demande d'autorisation a été envoyée. Cette comparaison DOIT utiliser une comparaison de chaînes simple telle que définie dans la section 6.2.1 de [RFC3986]. Si la valeur ne correspond pas à l'identifiant de l'émetteur attendu, les clients DOIVENT rejeter la réponse d'autorisation et NE DOIVENT PAS procéder à l'octroi de l'autorisation. Pour les réponses d'erreur, les clients NE DOIVENT PAS supposer que l'erreur provient du serveur d'autorisation prévu.

More precisely, clients that interact with authorization servers supporting OAuth metadata [RFC8414] MUST compare the iss parameter value to the issuer value in the server's metadata document. If OAuth metadata is not used, clients MUST use deployment-specific ways (for example, a static configuration) to decide if the returned iss value is the expected value in the current flow (see also Section 4).

Plus précisément, les clients qui interagissent avec des serveurs d'autorisation prenant en charge les métadonnées OAuth [RFC8414] DOIVENT comparer la valeur du paramètre iss à la valeur issuer dans le document de métadonnées du serveur. Si les métadonnées OAuth ne sont pas utilisées, les clients DOIVENT utiliser des moyens spécifiques au déploiement (par exemple, une configuration statique) pour décider si la valeur iss renvoyée est la valeur attendue dans le flux actuel (voir également la section 4).

If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients MUST retain state about whether each authorization server supports the iss parameter. Clients MUST reject authorization responses without the iss parameter from authorization servers that do support the parameter according to the client's configuration. Clients SHOULD discard authorization responses with the iss parameter from authorization servers that do not indicate their support for the parameter. However, there might be legitimate authorization servers that provide the iss parameter without indicating their support in their metadata. Local policy or configuration can determine whether to accept such responses, and specific guidance is out of scope for this specification.

Si les clients interagissent à la fois avec des serveurs d'autorisation prenant en charge cette spécification et des serveurs d'autorisation ne prenant pas en charge cette spécification, les clients DOIVENT conserver l'état indiquant si chaque serveur d'autorisation prend en charge le paramètre iss. Les clients DOIVENT rejeter les réponses d'autorisation sans le paramètre iss des serveurs d'autorisation qui prennent en charge le paramètre selon la configuration du client. Les clients DEVRAIENT rejeter les réponses d'autorisation avec le paramètre iss des serveurs d'autorisation qui n'indiquent pas leur prise en charge du paramètre. Cependant, il peut y avoir des serveurs d'autorisation légitimes qui fournissent le paramètre iss sans indiquer leur prise en charge dans leurs métadonnées. La politique locale ou la configuration peut déterminer s'il faut accepter de telles réponses, et des conseils spécifiques sortent du cadre de cette spécification.

In general, clients that support this specification MAY accept authorization responses that do not contain the iss parameter or reject them and exclusively support authorization servers that provide the iss parameter in the authorization response. Local policy or configuration can determine when to accept such responses, and specific guidance is out of scope for this specification.

En général, les clients qui prennent en charge cette spécification PEUVENT accepter des réponses d'autorisation qui ne contiennent pas le paramètre iss ou les rejeter et prendre en charge exclusivement les serveurs d'autorisation qui fournissent le paramètre iss dans la réponse d'autorisation. La politique locale ou la configuration peut déterminer quand accepter de telles réponses, et des conseils spécifiques sortent du cadre de cette spécification.

In OpenID Connect [OIDC.Core] flows where an ID Token is returned from the authorization endpoint, the value in the iss parameter MUST always be identical to the iss claim in the ID Token.

Dans les flux OpenID Connect [OIDC.Core] où un jeton d'ID est renvoyé par le point de terminaison d'autorisation, la valeur du paramètre iss DOIT toujours être identique à la revendication iss dans le jeton d'ID.

Section 4.1.2 of [RFC6749] already mandates that clients that do not support this specification MUST ignore the unrecognized iss parameter.

La section 4.1.2 de [RFC6749] exige déjà que les clients qui ne prennent pas en charge cette spécification DOIVENT ignorer le paramètre iss non reconnu.

Note: The "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)" [JARM] defines a mechanism that conveys all authorization response parameters in a JSON Web Token (JWT). This JWT contains an iss claim that provides the same protection if it is validated as described in Section 2.4. Therefore, an additional iss parameter outside the JWT is not necessary when JARM is used.

Note : Le "Mode de réponse d'autorisation sécurisée JWT pour OAuth 2.0 (JARM)" [JARM] définit un mécanisme qui transmet tous les paramètres de réponse d'autorisation dans un jeton Web JSON (JWT). Ce JWT contient une revendication iss qui offre la même protection si elle est validée comme décrit dans la section 2.4. Par conséquent, un paramètre iss supplémentaire en dehors du JWT n'est pas nécessaire lorsque JARM est utilisé.