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.

クライアントは、セクション 2.4 で説明されているとおりに iss パラメータを正確に検証する必要があり (MUST)、複数の認可サーバーが同じ発行者識別子を使用することを許可してはなりません (MUST NOT)。特に、認可サーバーの詳細をクライアントで手動で構成できる場合、クライアントは、受け入れられる iss 値が各認可サーバーで一意であることを確認する必要があります (MUST)。

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.

iss パラメータにより、クライアントは、認可サーバーが特定のトークンエンドポイントおよびユーザー情報エンドポイント [OIDC.Core] などの他のエンドポイントとともに OAuth フローで使用されることを「期待」しているかどうかを判断できます。OAuth メタデータが使用される場合、iss パラメータは発行者を識別するため、他のエンドポイントを指すそれぞれの OAuth メタデータドキュメントを識別します。OAuth メタデータが使用されない場合、クライアントは、たとえば、構成された各認可サーバーに対して静的に構成された予想される iss 値を使用できます。

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.

認可応答に含まれる発行者識別子は、改ざんに対して暗号化によって保護されていません。一般に、JWT（[JARM] で指定されているなど）などのメカニズムを使用して、認可応答の整合性を保護できます。ただし、ミックスアップ攻撃では、クライアントは通常、侵害されていない認可サーバーから認可応答を受け取ります。攻撃者がクライアントに受信される前にこの認可応答を改ざんできる場合、攻撃者は認可コードにも直接アクセスできます。攻撃者は、認可コードを盗むためにミックスアップ攻撃を実行する必要はありません。したがって、認可応答の整合性保護は、ミックスアップ攻撃に対する防御には必要ありません。

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.

ミックスアップ攻撃に対する代替の対策もあります。認可応答に他の手段で認可サーバーの発行者識別子がすでに含まれており、この識別子がセクション 2.4 に示されているようにチェックされている場合、iss パラメータの使用と検証は不要であり、省略される場合があります (MAY)。たとえば、認可エンドポイントから ID トークンを返す OpenID Connect 応答タイプ（たとえば、response_type=code id_token）または [JARM] が使用されている場合がこれに該当します。ただし、クライアントが複数の発行者識別子を含む認可応答を受信した場合、これらの発行者識別子が一致しない場合、クライアントは応答を拒否する必要があります (MUST)。代替の対策の詳細は、本仕様の範囲外です。

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.

ミックスアップ攻撃は、複数の認可サーバーと対話するクライアントにのみ関連します。ただし、1つの認可サーバーとのみ対話するクライアントは、将来的に2番目の認可サーバーのサポートを追加する可能性があります。複数の認可サーバーをサポートすることにより、それらはミックスアップ攻撃に対して脆弱になり、対策を適用する必要があります。