メインコンテンツまでスキップ

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.

クライアントへの認可応答（エラー応答を含む）では、本仕様をサポートする認可サーバーは、応答に iss パラメータを含めることでその身元を示す必要があります (MUST)。

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.

iss パラメータ値は、[RFC8414] で定義されているように、認可応答を作成した認可サーバーの発行者識別子です。その値は、クエリまたはフラグメントコンポーネントを含まない "https" スキームを使用する URL でなければなりません (MUST)。

2.1. Example Authorization Response​

2.1. 認可応答の例​

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):

次の例は、発行者識別子が https://honest.as.example である認可サーバーからの認可応答を示しています（余分な改行とインデントは表示のみを目的としています）：

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. エラー応答の例​

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

次の例は、同じ認可サーバーからのエラー応答を示しています（余分な改行とインデントは表示のみを目的としています）：

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. 発行者識別子の提供​

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

本仕様をサポートする認可サーバーは、クライアントが iss パラメータを効果的に検証できるように、発行者識別子を提供する必要があります (MUST)。

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

[RFC8414] に従ってメタデータを公開する認可サーバーの場合、次のルールが適用されます：

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

  • サーバーのメタデータ値 issuer に含まれる発行者識別子は、iss パラメータの値と同一でなければなりません (MUST)。

  • 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.

  • サーバーは、セクション 3 で定義されているメタデータパラメータ authorization_response_iss_parameter_supported を true に設定することにより、iss パラメータのサポートを示す必要があります (MUST)。

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

認可サーバーは、他のメカニズムによってクライアントに発行者識別子を追加で提供する場合があり (MAY)、これは本仕様の範囲外です。

2.4. Validating the Issuer Identifier​

2.4. 発行者識別子の検証​

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.

本仕様をサポートするクライアントは、パラメータが存在する場合、受信した認可応答から iss パラメータの値を抽出する必要があります (MUST)。次に、クライアントは、[RFC6749] の付録 B に従って "application/x-www-form-urlencoded" 形式から値をデコードし、その結果を、認可要求が送信された認可サーバーの発行者識別子と比較する必要があります (MUST)。この比較では、[RFC3986] のセクション 6.2.1 で定義されている単純な文字列比較を使用する必要があります (MUST)。値が予想される発行者識別子と一致しない場合、クライアントは認可応答を拒否する必要があり (MUST)、認可グラントを続行してはなりません (MUST NOT)。エラー応答の場合、クライアントはエラーが意図した認可サーバーから発生したと想定してはなりません (MUST NOT)。

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).

より正確には、OAuth メタデータ [RFC8414] をサポートする認可サーバーと対話するクライアントは、iss パラメータ値をサーバーのメタデータドキュメント内の issuer 値と比較する必要があります (MUST)。OAuth メタデータが使用されていない場合、クライアントは、展開固有の方法（たとえば、静的構成）を使用して、返された iss 値が現在のフローで予想される値であるかどうかを判断する必要があります (MUST)（セクション 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.

クライアントが、本仕様をサポートする認可サーバーとサポートしない認可サーバーの両方と対話する場合、クライアントは各認可サーバーが iss パラメータをサポートしているかどうかについての状態を保持する必要があります (MUST)。クライアントは、クライアントの構成に従ってパラメータをサポートする認可サーバーからの iss パラメータのない認可応答を拒否する必要があります (MUST)。クライアントは、パラメータのサポートを示さない認可サーバーからの iss パラメータを含む認可応答を破棄する必要があります (SHOULD)。ただし、メタデータでサポートを示さずに iss パラメータを提供する正当な認可サーバーが存在する場合があります。ローカルポリシーまたは構成によって、そのような応答を受け入れるかどうかを決定でき、具体的なガイダンスは本仕様の範囲外です。

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.

一般に、本仕様をサポートするクライアントは、iss パラメータを含まない認可応答を受け入れるか、それらを拒否し、認可応答で iss パラメータを提供する認可サーバーのみをサポートすることができます (MAY)。ローカルポリシーまたは構成によって、そのような応答をいつ受け入れるかを決定でき、具体的なガイダンスは本仕様の範囲外です。

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.

認可エンドポイントから ID トークンが返される OpenID Connect [OIDC.Core] フローでは、iss パラメータの値は常に ID トークン内の iss クレームと同一でなければなりません (MUST)。

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

[RFC6749] のセクション 4.1.2 では、本仕様をサポートしないクライアントは認識されない iss パラメータを無視しなければならない (MUST) ことがすでに義務付けられています。

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.

注: "OAuth 2.0 の JWT セキュア認可応答モード (JARM)" [JARM] は、JSON Web Token (JWT) ですべての認可応答パラメータを伝達するメカニズムを定義しています。この JWT には、セクション 2.4 で説明されているように検証された場合に同じ保護を提供する iss クレームが含まれています。したがって、JARM を使用する場合、JWT の外側の追加の iss パラメータは必要ありません。

に最終更新