[要約] RFC 9700は、OAuth 2.0のセキュリティに関する最新のベストプラクティス（BCP）を定義した文書です。インプリシットグラントやパスワードグラントの使用を禁止（または強く非推奨）し、パブリッククライアントに対するPKCE（Proof Key for Code Exchange）の必須化や認可サーバーによるPKCEサポートの義務化など、要件を厳格化しています。トークン漏洩、リプレイ攻撃、オープンリダイレクトといった現代的な脅威への対策を網羅し、より堅牢な認証・認可システムを実装するための具体的な指針を提供しています。
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における最新のセキュリティのベストプラクティスを解説しています。RFC 6749、6750、および6819に記載されている脅威モデルとセキュリティアドバイスを更新・拡張し、OAuth 2.0の公開以降に得られた実践的な経験を取り入れるとともに、OAuth 2.0の適用範囲の拡大に伴う新たな脅威にも対応しています。さらに、安全性が低い、あるいは安全ではないと判断される一部の動作モードについては、非推奨としています。
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」と表記）は市場で大きな注目を集め、API保護の標準となり、OpenID Connect [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は、オープンバンキング、eヘルス、電子政府、電子署名など、当初想定されていたよりも高いセキュリティ要件が求められる環境で使用されています。これらのユースケースでは、より厳格なガイドラインと追加の保護が求められます。
* 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を事前に登録されたURIと比較する場合、認可サーバーは、ネイティブアプリのlocalhostリダイレクト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フローでは、nonceパラメータがCSRF保護を提供します。それ以外の場合、ユーザーエージェントに安全にバインドされたstateパラメータで伝達されるワンタイム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チャレンジまたは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サポートを検出するために使用できる）を含む `code_challenge_methods_supported` 要素を認可サーバーメタデータ [RFC8414] で公開することが推奨されます。認可サーバーは代わりに、認可サーバーによる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.
認可サーバーが認可応答でアクセストークンを発行する暗黙のグラント（応答タイプ `token`）およびその他の応答タイプは、セクション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.
これらの問題を回避するために、認可応答でのアクセストークンインジェクションが防止され、前述のトークン漏洩経路が軽減されない限り、クライアントは暗黙のグラント（応答タイプ `token`）または認可応答でアクセストークンを発行するその他の応答タイプを使用すべきではありません。
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` (すなわち、認可コードグラントタイプ) または、`code id_token` 応答タイプなどの、認可サーバーがトークン応答でアクセストークンを発行するその他の応答タイプを使用すべきです。これにより、認可サーバーは攻撃者によるリプレイの試みを検出し、アクセストークンが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.
特に、アクセストークンは、特定のリソースサーバーに限定されるべきです。それが実行不可能な場合は、少数のリソースサーバーに限定されるべきです。これを実現するために、認可サーバーはアクセストークンを特定のリソースサーバーに関連付け、すべてのリソースサーバーは、すべてのリクエストに対して、そのリクエストで送信されたアクセストークンがその特定のリソースサーバーで使用されることを意図していたかどうかを検証する義務があります。意図していなかった場合、リソースサーバーは当該リクエストの提供を拒否しなければなりません。[RFC9068]で定義されている`aud`クレームは、アクセストークンのオーディエンス制限に使用できます。クライアントと認可サーバーは、[RFC6749]と[RFC8707]でそれぞれ指定されているパラメータ `scope` または `resource` を利用して、アクセスしたいリソースサーバーを決定してもよいでしょう。
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.
さらに、アクセストークンは、リソースサーバーまたはリソース上の特定のリソースとアクションに制限されるべきです。これを実現するために、認可サーバーはアクセストークンをそれぞれのリソースとアクションに関連付け、すべてのリソースサーバーは、すべてのリクエストに対して、そのリクエストで送信されたアクセストークンが特定のリソースの特定の目的で使用されることを意図していたかどうかを検証する義務があります。意図していなかった場合、リソースサーバーは当該リクエストの提供を拒否しなければなりません。クライアントと認可サーバーは、[RFC6749]で指定されているパラメータ `scope` および [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要素認証および認証プロセスでの動作を想定して設計されていません。暗号化資格情報（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.
クライアント認証には、OAuth 2.0 の相互 TLS [RFC8705] や、[RFC7521] および [RFC7523] に準拠した署名付き JWT (「Private Key JWT」) などの非対称暗号化を使用することが推奨されます。後者は [OpenID.Core] でクライアント認証方法 private_key_jwt として定義されています。クライアント認証に非対称暗号化を使用する場合、認可サーバーは機密性の高い対称鍵を保存する必要がないため、これらの方法は鍵の漏洩に対してより堅牢になります。
The use of OAuth Authorization Server Metadata [RFC8414] can help to improve the security of OAuth deployments:
OAuth認可サーバーメタデータ [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認可サーバーメタデータを公開し、クライアントがこの認可サーバーメタデータ（利用可能な場合）を利用して自身を構成することが推奨されます。
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で説明されている条件下では、認可サーバーは、クライアントがその `client_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.
* ブラウザ（履歴）、プロキシサーバー、およびオペレーティングシステムによって保存/ログに記録されるURL。
(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）は、リソース所有者であるか、あるいはそのように行動できることに注意してください。たとえば、そのような攻撃者は、クライアントまたはリソースサーバーにおいて、上記の攻撃のいずれかによって取得されたトークンまたは認可コードをリプレイするために、自身のブラウザを使用できます。
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:
グラントタイプ`code`を使用するクライアントの場合、攻撃は次のように機能する可能性があります。
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.
クライアントID s6BhdRkqt3を持つクライアントに対して、リダイレクトURLパターン https://*.somesite.example/* が登録されていると仮定します。意図としては、somesite.example のどのサブドメインもクライアントの有効なリダイレクトURIとして許可することです（例：https://app1.somesite.example/redirect）。しかし、認可サーバー上の素朴な実装では、ワイルドカード「*」を「任意の文字」と解釈し、「ドメイン名として有効な任意の文字」と解釈しない場合があります。したがって、認可サーバーは https://attacker.example/.somesite.example をリダイレクトURIとして許可する可能性がありますが、attacker.example は悪意のある第三者によって制御される可能性のある異なるドメインです。
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).
まず、攻撃者はユーザーを騙して、攻撃者の制御下にあるページ（例：https://www.evil.example、セクション3の攻撃者A1を参照）を起動する改ざんされた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を使用して、認可エンドポイントに以下の認可リクエストを開始します（表示のため改行しています）。
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.
認可サーバーはリダイレクト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]によるとパブリッククライアントには推奨されません）、ユーザーの操作なしでも攻撃を実行できます。
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レコード（例：external-service.somesite.example）が、もはや存在しない外部DNS名（例：customer-abc.service.example）を指しており、攻撃者によって乗っ取られる（例：外部サービスにcustomer-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`を使用する他のグラントも）は、別の種類の攻撃を受ける可能性があります。この攻撃は、Locationヘッダーにフラグメントが含まれていない場合、ユーザーエージェントがリダイレクトの宛先URLにフラグメントを再付与するという事実を利用しています（[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?*であると仮定します。つまり、https://client.somesite.example/cbへのリダイレクトには任意のパラメータが許可されます。残念ながら、このクライアントはオープンリダイレクターを公開しています。このエンドポイントは、ターゲットURLを受け取る`redirect_to`パラメータをサポートしており、HTTP Locationヘッダーの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.
まず、上記と同様に、攻撃者はユーザーを騙して、攻撃者の制御下にあるページ（例：https://www.evil.example）を起動する改ざんされたURLをブラウザで開かせます。
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サイトは、コードフローへの攻撃と非常によく似た認可リクエストを開始します。上記とは異なり、リダイレクトURIのパラメータに `redirect_to=https://attacker.example` をエンコードすることでオープンリダイレクターを利用し、応答タイプ `token` を使用します（表示のため改行しています）。
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 Locationヘッダーリダイレクトを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 のリダイレクターは Location ヘッダーにフラグメントを含んでいないため、ユーザーエージェントは元のフラグメント `#access_token=2YotnFZFEjr1zCsicMWpAA&...` を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.
攻撃者の attacker.example のページは、その後フラグメントにアクセスし、アクセストークンを取得できます。
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「単純な文字列比較」を参照してください。唯一の例外は、localhost 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.
* ブラウザは、Locationヘッダー内のURLにフラグメントがまだ含まれていない場合にのみ、URLフラグメントをLocationリダイレクトURLに再付与します。したがって、サーバーは、Locationヘッダー内の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.
* クライアントは、認可エンドポイントでアクセストークンを発行させる応答タイプの代わりに、認可コード応答タイプを使用すべきです。これにより、認可サーバーとの交換プロセスを通じて漏洩したクレデンシャルの再利用を防ぎ、アクセストークンの送信者制約を通じてトークンリプレイを防ぐ対策となります。
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または認可応答URIの内容は、Referer HTTPヘッダーを通じて（[RFC9110]のセクション10.1.3を参照）、認可サーバーまたはクライアントのウェブサイトからそれぞれ漏洩することによって、意図せず攻撃者に開示される可能性があります。最も重要なのは、認可コードやstate値がこの方法で開示される可能性があることです。[RFC9110]のセクション10.1.3では別段の指定がされていますが、Chromiumプロジェクトにおける（現在は修正された）問題[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を受け取り、コードまたはstate（そして潜在的に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.
同様に、認可サーバーの認可エンドポイントが上記のようなリンクやサードパーティのコンテンツを含んでいる場合、攻撃者は認可リクエストからstateを学習できます。
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].
Refererヘッダーを通じて有効なコードまたはアクセストークンを学習した攻撃者は、セクション4.1.1、4.5、および4.6で説明されている攻撃を実行できます。攻撃者がstateを学習すると、stateの使用によって達成される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.
* 適切なReferrer Policy [W3C.webappsec-referrer-policy]をドキュメントに適用すること（「referrer」メタ属性の一部として、またはReferrer-Policyヘッダーを設定することによって）でRefererヘッダーを抑制します。例えば、応答に`Referrer-Policy: no-referrer`ヘッダーを設定すると、結果のドキュメントから発生するすべてのリクエストにおいてRefererヘッダーが完全に抑制されます。
* 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.)
* state値は、リダイレクトエンドポイントで最初に利用された後、クライアントによって無効化されるべきです。これが実装され、攻撃者がクライアントのウェブサイトからRefererヘッダーを通じてトークンを受け取った場合、stateはすでに使用され、クライアントによって無効化されており、攻撃者は再度使用できません。（これは、stateが認可サーバーのウェブサイトから漏洩した場合、クライアントのリダイレクトエンドポイントでまだstateが使用されていないため、役に立ちません。）
* 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.
認可コードとアクセストークンは、ブラウザの訪問履歴に残り、以下の攻撃を可能にする可能性があります。
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/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.
アクセストークンは、クライアントまたはすでにトークンを持つウェブサイトが意図的に `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/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クエリパラメータでアクセストークンを渡してはなりません。この目的のために、認可コードグラントまたはフォームポスト応答モード[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
* 暗黙的または認可コードグラントが複数の認可サーバーで使用され、そのうち1つは「正直な」（H-AS）と見なされ、もう1つは攻撃者（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, クライアントID: 7ZGZldHQ）およびA-AS（URI: https://attacker.example, クライアント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を使用してグラントを開始することを選択します（例：クライアントのウェブサイト上のボタンをクリックして）。
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」を選択したことをユーザーのセッションに保存し、Locationヘッダーに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に置き換えます。したがって、ブラウザはLocationヘッダーに `https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ` を指すリダイレクト（303 See Other）を受け取ります。
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の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]メカニズムの機能を悪用したり、アクセストークンやIDトークンをリプレイしてミックスアップ攻撃を実行したりします。攻撃の詳細は、[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認可サーバーメタデータ[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.
認可サーバーの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.
認可コードインジェクション攻撃では、攻撃者は盗まれた認可コードを、クライアントにおける攻撃者自身のセッションに注入しようと試みます。目的は、クライアントにおける攻撃者のセッションを被害者のリソースまたはIDと関連付け、それによって攻撃者に被害者のリソースへの少なくとも限定的なアクセスを与えることです。
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.
* 攻撃者がこの特定のクライアントの特定の機能にアクセスしたい場合。例えば、攻撃者が特定のアプリや特定のウェブサイトで被害者になりすましたい場合。
* 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、クライアントシークレット（またはその他のクライアント認証手段）とともに、コードを認可サーバーのトークンエンドポイントに送信します。
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. すべてのチェックが成功し、認可サーバーはクライアントにアクセスおよびその他のトークンを発行します。攻撃者はこれで、正当なクライアントとの自身のセッションを被害者のリソースおよび/またはIDと関連付けました。
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`パラメータが含まれていた場合、それが存在することを保証し、もし含まれていた場合はその値が同一であることを保証します。
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自体に、nonceまたは別の種類のワンタイム使用の秘密データが含まれていること、および
* 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.
他のプロバイダーは、登録されたリダイレクトURIパターンに対して`redirect_uri`パラメータを単にパターンマッチングします。これにより、認可サーバーは、実際の`redirect_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値はワンタイム使用でクライアントによって生成されます。クライアントはこれをユーザーエージェントセッションにバインドし、最初のリクエストとともにOpenIDプロバイダー（OP）に送信することになっています。OPは受信した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を検証しなければなりません。たとえ別のIDトークンが認可応答（例：`response_type=code+id_token`）から取得されたとしても同様です。
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.
攻撃者は認可コードインジェクション攻撃を実行する必要がないため、nonceはパブリッククライアントの認可コードを保護しないことに注意することが重要です。代わりに、攻撃者は盗まれた認可コードでトークンエンドポイントを直接呼び出すことができます。
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.
コードへのstateのバインド、暗号化手段を用いたコードの送信者制約、またはインスタンスごとのクライアントクレデンシャルといった他の解決策も考えられますが、これらはサポートが不足しており、新たなセキュリティ要件をもたらします。
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でクライアントが自身のセッションで選択した値と同じになるように変更できます。（これには、攻撃者がクライアントとのセッションを開始した後に、被害者のクライアントとのセッションが開始されることが必要です。）その後、攻撃者が被害者から認可コードを傍受できた場合、PKCEまたはnonceが使用されていても、攻撃者はステップ3で盗まれたコードを注入できるようになります。
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フローを開始し、認可サーバーによって発行されたアクセストークンを置き換えたり、漏洩したアクセストークンを含む認可サーバー応答を直接作成したりすることで、認可応答を改変します。この応答には、この特定のトランザクションのためにクライアントによって生成されたstate値が含まれているため、クライアントはこの応答を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.
トークンがトランザクションや特定のユーザーエージェントへのバインディングなしで発行されるため、純粋なOAuthフローでは、このような注入攻撃を検出する方法はありません。
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.
長年確立されている対策は、クライアントがランダムな値（CSRFトークンとも呼ばれます）をstateパラメータで渡し、それによってリクエストをリダイレクト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保護のためにstateまたはnonceの代わりに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保護にはstateまたはnonceを使用しなければなりません。
* 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].
* stateがアプリケーション状態を伝達するために使用され、その内容の整合性が懸念される場合、クライアントはstateを改ざんおよびスワッピングから保護しなければなりません。これは、stateの内容をブラウザセッションにバインドすること、および/またはstate値を署名/暗号化することによって達成できます。この一例は、期限切れのインターネットドラフト[JWT-ENCODED-STATE]で議論されています。
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]に従った認可サーバーメタデータを使用することが推奨されますが、認可サーバーは代わりに、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は、認可応答を読み取ることができる攻撃者（セクション3の攻撃者（A3）を参照）が存在する場合でも、CSRF攻撃に対する堅牢な保護を提供します。stateが使用されるか、認可応答でIDトークンが返される場合（例：`response_type=code+id_token`）、攻撃者はstate値を学習して偽造された認可応答にリプレイするか、IDトークンからnonceを抽出し、それを認可サーバーへの新しいリクエストで使用して同じnonceを持つ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番目の前提条件は、クライアントがstateを全く使用していない（例：クライアントがCSRF防御のためにPKCEに依存しているため）か、クライアントがstateを正しくチェックしていないことです。
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. 認可サーバーが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. 攻撃者は、ユーザーのブラウザを、攻撃者の認可サーバーとのセッションのコードを含む認可応答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. ユーザーのブラウザは認可コードをクライアントに送信し、クライアントは認可サーバーでそのコードをアクセストークンと引き換えようとします。クライアントはトークンリクエストで`code_verifier=abc`をPKCEコードベリファイアとして送信します。
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. 認可サーバーは、このコードがいかなる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.
stateを適切に使用すれば、この攻撃は防止できます。しかし、実際には多くのOAuthクライアントがstateを適切に使用またはチェックしていないことが示されています。
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.
上記の攻撃において、認可サーバーの視点から見ると、認可コードが発行されたOAuthフローの認可リクエストには`code_challenge`パラメータが存在しなかったにもかかわらず、トークンエンドポイントで`code_verifier`パラメータが受信されることに注意してください。
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をサポートする認可サーバーは、認可リクエストにコードチャレンジが含まれているかどうかをチェックし、この情報を発行されるコードにバインドしなければなりません。そして、
* 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. 認可サーバーは、その特定のトークンを特定のクライアントにバインドするデータをアクセストークンと関連付けます。バインディングはクライアントのIDを利用できますが、ほとんどの場合、認可サーバーはクライアントに既知の鍵マテリアル（または鍵マテリアルから派生したデータ）を利用します。
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 Mutual-TLSクライアント認証と証明書バインドアクセストークン」[RFC8705]：このドキュメントで指定されたアプローチは、クライアント認証と送信者制約付きアクセストークンの両方に相互TLSの使用を許可します。送信者制約付きアクセストークンの目的のために、クライアントは公開鍵のフィンガープリントによってリソースサーバーに対して識別されます。アクセストークンリクエストの処理中に、認可サーバーは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は、アクセスおよびリフレッシュトークンを送信者制約するアプリケーションレベルのメカニズムを概説しています。これは、公開鍵/秘密鍵ペアとアプリケーションレベル署名に基づいた所有証明を使用します。DPoPはパブリッククライアントで使用でき、機密クライアントの場合は、任意のクライアント認証方法と組み合わせることができます。
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.
オーディエンス制限は、本質的にアクセストークンを特定のリソースサーバーに限定します。認可サーバーはアクセストークンを特定のリソースサーバーに関連付け、リソースサーバーは意図されたオーディエンスを検証することになっています。アクセストークンが意図されたオーディエンスの検証に失敗した場合、リソースサーバーは該当するリクエストの提供を拒否します。
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.
認可サーバーがすべてのリソースサーバーの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の代わりに、リソースサーバーの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]で指定されているリソースインジケーターがこれを達成するのに役立ちます）。[TOKEN-BINDING]も同様の特性を持っていました。異なるトークンバインディング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.
オーディエンス制限、または一般的に言えば、クライアントがアクセストークンを使用したい場所を認可サーバーに指示することは、トークン漏洩防止の範囲を超えた追加の利点があることに注意すべきです。これらは、認可サーバーが、その形式と内容が該当するサーバーのために特別に作成された異なるアクセストークンを生成することを可能にします。これは、構造化されたアクセストークンを使用するデプロイメントにおいて、大きな機能的およびプライバシー上の利点をもたらします。
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.
認可サーバーは、クライアントに対して、そのアクセストークンを安全に使用できる場所に関する追加情報を提供できます。このアプローチ、およびそれが推奨されない理由については、以下で説明します。
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:
最も単純な形式では、これには認可サーバーが既知のリソースサーバーのリストを公開することが必要となります。以下の例では、非標準の認可サーバーメタデータパラメータ`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:
認可サーバーは、アクセストークンが有効な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]を参照）は、クライアント実装の大部分がstateチェックのようなセキュリティ制御を適切に実装しない、または実装に失敗することを示しています。したがって、アクセストークンのフィッシングを防ぐためにクライアントに依存することも失敗する可能性が高いです。さらに、クライアントと認可サーバーおよびリソースサーバーの比率を考えると、セキュリティ関連のロジックを可能な限りそれらのサーバーに移動する方がより実現可能なアプローチと見なされます。明らかに、クライアントは全体のセキュリティに貢献する必要があります。しかし、関与する当事者間のより良いバランスを提供する、セクション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.
認可サーバーまたはクライアントがオープンリダイレクターを持っている場合、以下の攻撃が発生する可能性があります。このようなエンドポイントは、例えば、ユーザーが外部ウェブサイトにリダイレクトされる前にメッセージを表示するため、またはログインプロンプトなどによって中断される前に訪問しようとしていたURLにユーザーをリダイレクトするために、実装されることがあります。
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.
クライアントはオープンリダイレクターを公開してはなりません。攻撃者はオープンリダイレクターを利用して、クライアントを指すURLを作成し、それらを利用して認可コードとアクセストークンを漏洩させる可能性があります（セクション4.1.2を参照）。別の悪用ケースとしては、クライアントを指しているように見える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認可サーバーは通常、ユーザーを他のウェブサイト（クライアント）にリダイレクトしますが、これを安全に行わなければなりません。
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.
認可サーバーは、これらの脅威を防ぐための予防措置を講じなければなりません。認可サーバーは、常に最初にユーザーを認証し、サイレント認証のユースケースを除き、ユーザーをリダイレクトする前に、必要に応じてユーザーにクレデンシャルの入力を促さなければなりません。リスクアセスメントに基づいて、認可サーバーはリダイレクト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.
認可サーバーは、リダイレクト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.
認可エンドポイントでは、典型的なプロトコルフローとして、認可サーバーがユーザーにフォームでクレデンシャルを入力するよう促し、そのフォームが（HTTP POSTメソッドを使用して）認可サーバーに送信されます。認可サーバーはクレデンシャルをチェックし、成功した場合、ユーザーエージェントをクライアントのリダイレクトエンドポイントにリダイレクトします。
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（Found）が使用されますが、「ユーザーエージェントを介してこのリダイレクションを達成するために利用可能な他の任意の方法も許可されます」。代わりにリダイレクションにステータスコード307が使用される場合、ユーザーエージェントはユーザーのクレデンシャルをHTTP POSTを介してクライアントに送信します。
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.
これにより、機密性の高いクレデンシャルがクライアントに開示されます。クライアントが悪意を持っている場合、そのクレデンシャルを使用して認可サーバーでユーザーになりすますことができます。
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を含む他のすべてのステータスコードの場合、ユーザーエージェントはPOSTをGETリクエストに書き換えないことを選択でき、その結果、ユーザーのクレデンシャルがクライアントに開示される可能性があります。（ただし、実際にはほとんどのユーザーエージェントは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（See Other）を使用すべきです。
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.
リフレッシュトークンは、新しいアクセストークンを取得するための便利でユーザーフレンドリーな方法です。また、認可サーバーが短いライフタイムと限定されたスコープでアクセストークンを発行できるため、アクセストークン漏洩の潜在的な影響を軽減できることから、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,
* 認可サーバーとクライアント間の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.
認可サーバーは、リスク評価に基づいて、特定のクライアントにリフレッシュトークンを発行するかどうかを決定しなければなりません。認可サーバーがリフレッシュトークンを発行しないと決定した場合、クライアントは認可コードグラントタイプなどの他のグラントタイプを利用して新しいアクセストークンを取得してもよいでしょう。そのような場合、認可サーバーはユーザーエクスペリエンスを最適化するために、クッキーと永続的なグラントを利用してもよいでしょう。
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].
* *送信者制約付きリフレッシュトークン：* 認可サーバーは、[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.
* *リフレッシュトークンローテーション：* 認可サーバーは、アクセスを伴うトークンリフレッシュ応答ごとに新しいリフレッシュトークンを発行します。以前のリフレッシュトークンは無効化されますが、その関係に関する情報は認可サーバーによって保持されます。リフレッシュトークンが侵害され、その後攻撃者と正当なクライアントの両方によって使用された場合、どちらか一方が無効なリフレッシュトークンを提示することになり、それが認可サーバーに侵害を通知します。認可サーバーは、どのパーティが無効なリフレッシュトークンを提出したかを判断できませんが、アクティブなリフレッシュトークンは失効させられます。これにより、正当なクライアントに新たな認可グラントの取得を強制するコストを伴うものの、攻撃が停止します。
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.
* 認可サーバーでのログアウト。
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:
リソースサーバーは、アクセストークンが発行されたリソース所有者の識別子に基づいて、またはクライアントクレデンシャルグラントにおけるクライアントの識別子に基づいて、アクセス制御の決定を行う場合があります。たとえば、[RFC9068]（OAuth 2.0アクセストークンのJSON Web Token（JWT）プロファイル）は、以下のように定義された`sub`クレームを含むアクセストークンのデータ構造を記述しています。
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.
認可コードグラントなど、リソース所有者が関与するグラントを通じて取得されたアクセストークンの場合、"sub" の値はリソース所有者のサブジェクト識別子に対応すべきです。クライアントクレデンシャルグラントなど、リソース所有者が関与しないグラントを通じて取得されたアクセストークンの場合、"sub" の値は認可サーバーがクライアントアプリケーションを示すために使用する識別子に対応すべきです。
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.
両方のオプションが可能である場合、リソースサーバーはクライアントの識別子をリソース所有者の識別子と誤認する可能性があります。たとえば、クライアントが認可サーバーへの登録中に自身の`client_id`を選択できる場合、悪意のあるクライアントはそれをリソース所有者を識別する値（例：OpenID Connectが使用されている場合は`sub`値）に設定する可能性があります。リソースサーバーが、リソース所有者の関与なしに取得されたアクセストークンと、リソース所有者の関与ありで取得されたアクセストークンを適切に区別できない場合、クライアントは意図せずにリソース所有者に属するリソースにアクセスできる可能性があります。
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とユーザー識別子に共通の名前空間が存在する場合（例えば、上記のセクション4.15に示されている[RFC9068]の`sub`クレームの例のように）、クライアントがその `client_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-Frame-Options HTTP応答ヘッダーフィールドの使用やフレームバスターJavaScriptを含む複数の対策が記載されています。これらに加えて、認可サーバーはContent Security Policy（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は、フレームのオリジンを制限するポリシー（frame-ancestorsを使用）と、HTMLページで実行を許可されるスクリプトのソースを制限するポリシー（script-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を介して認可応答またはトークン応答を送信する場合、認可サーバーはクライアントのオリジンではなく、ワイルドカードオリジン「*」に応答を送信します。応答が送信されるウィンドウが攻撃者によって制御される場合、攻撃者は応答を読み取ることができます。
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.
postMessageを介して認可応答またはトークン応答を期待するクライアントは、メッセージの送信オリジンを検証しない可能性があります。これにより、攻撃者がクライアントに認可応答またはトークン応答を注入できる可能性があります。
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で説明されているように、厳密な文字列マッチングを利用しなければなりません。認可サーバーは、以下の非規範的な例に示すように、信頼できるクライアントの受信オリジンにpostMessageを送信しなければなりません。
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).
攻撃者がそれらを使用して被害者のブラウザ内メッセージを悪意のあるオリジンに漏洩させる可能性があるため、postMessageでの「*」のようなワイルドカードオリジンを使用してはなりません。どちらの対策も、認可コードとアクセストークンの漏洩防止に貢献します（セクション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リダイレクトの代わりにpostMessage）を適用するだけなので、セクション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
Daniel Fett
Authlete
Email: mail@danielfett.de