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.
OAuth 2.0 認可フレームワーク [RFC6749] により、クライアントは、別々のエンティティの制御下にある複数の独立した認可サーバーと対話できます。一部の OAuth グラントタイプは、リソース所有者のユーザーエージェントを利用して、認可サーバーの応答を OAuth クライアントに配信します。このパターンの1つの例は、認可コードグラントの認可応答です。
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".
[RFC6749] のセクション 4.1.2 で指定されている認可応答には、応答を発行した認可サーバーの身元に関する情報は含まれていません。したがって、リソース所有者のユーザーエージェントから応答を受信するクライアントは、誰が最初に応答とその中に含まれる秘密を発行したのかを確信できません。応答の起源に関する確実性の欠如により、「ミックスアップ攻撃 (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].
ミックスアップ攻撃は、複数の認可サーバーと対話するすべての OAuth クライアントに対する潜在的な脅威です。これらの認可サーバーの少なくとも1つが攻撃者の制御下にある場合、攻撃者はミックスアップ攻撃を開始して、他の認可サーバーのいずれかによって発行された認可コードまたはアクセストークンを取得できます。攻撃者がクライアントによってサポートされている認可サーバーの制御を取得する方法は複数あります。たとえば、認可サーバーが侵害される可能性や、攻撃者が動的クライアント登録 [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.
1つの認可サーバーとのみ対話する OAuth クライアントは、ミックスアップ攻撃に対して脆弱ではありません。ただし、そのようなクライアントが将来、2番目の認可サーバーのサポートを追加することを決定した場合、脆弱になり、ミックスアップ攻撃への対策を適用する必要があります。
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].
ミックスアップ攻撃は、クライアントをだまして、正当な認可サーバーまたはリソースサーバーではなく攻撃者に認可コードまたはアクセストークンを送信させることにより、認可コードまたはアクセストークンを盗むことを目的としています。これは、アクセスが OAuth で管理されているリソースの機密性と完全性に対する深刻な脅威となります。ミックスアップ攻撃クラスの詳細な説明とさまざまなバリエーションは、「OAuth 2.0 Security Best Current Practice」[OAUTH-SECURITY-TOPICS] のセクション 4.4、およびこの攻撃クラスを最初に強調した独自の研究である「On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect」[arXiv.1508.04324] および「A Comprehensive Formal Security Analysis of 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.
このドキュメントでは、認可応答に iss と呼ばれる新しいパラメータを定義します。iss パラメータを使用すると、認可サーバーは認可応答にその身元を明示的に含めることができます。クライアントは、iss パラメータの値を、対話していると信じている認可サーバーの発行者識別子（たとえば、そのメタデータから取得したもの）と比較できます。iss パラメータは、クライアントに認可サーバーの身元に関する確実性を与え、認可コードやアクセストークンなどの資格情報を意図した受信者にのみ送信できるようにします。
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].
ミックスアップ攻撃に対する iss パラメータの有効性は、「A Comprehensive Formal Security Analysis of OAuth 2.0」[arXiv.1601.01229] で分析され、正式に証明されました。
1.1. Conventions and Terminology
1.1. 表記規則と用語
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] で説明されているように、すべて大文字で表示される場合にのみ解釈されます。
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].
この仕様では、OAuth 2.0 認可フレームワーク [RFC6749] で定義されている用語「アクセストークン」、「認可コード」、「認可コードグラント」、「認可サーバー」、「リソースサーバー」、「認可応答」、「グラントタイプ」、および「クライアント」を使用します。「発行者識別子」という用語は、OAuth 2.0 認可サーバーメタデータ [RFC8414] で定義されています。