[要約] RFC 6819は、OAuth 2.0プロトコルのセキュリティ脅威モデルとセキュリティ上の考慮事項を提供します。この文書の目的は、OAuth 2.0の実装者と利用者に、潜在的なセキュリティ脅威を理解し、それらに対処するためのガイドラインを提供することです。主に、OAuth 2.0を使用して認証と認可を行うWebアプリケーションやサービスの開発者が利用します。関連するRFCには、OAuth 2.0を定義するRFC 6749や、OAuth 2.0のトークン使用を拡張するRFC 6750などがあります。
Internet Engineering Task Force (IETF) T. Lodderstedt, Ed.
Request for Comments: 6819 Deutsche Telekom AG
Category: Informational M. McGloin
ISSN: 2070-1721 IBM
P. Hunt
Oracle Corporation
January 2013
OAuth 2.0 Threat Model and Security Considerations
OAuth 2.0脅威モデルとセキュリティの考慮事項
Abstract
概要
This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol.
このドキュメントでは、OAuth 2.0プロトコルの包括的な脅威モデルに基づいて、OAuth 2.0仕様に加えて、OAuthのセキュリティに関する追加の考慮事項について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6819.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6819で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................6
2. Overview ........................................................7
2.1. Scope ......................................................7
2.2. Attack Assumptions .........................................7
2.3. Architectural Assumptions ..................................8
2.3.1. Authorization Servers ...............................8
2.3.2. Resource Server .....................................9
2.3.3. Client ..............................................9
3. Security Features ...............................................9
3.1. Tokens ....................................................10
3.1.1. Scope ..............................................11
3.1.2. Limited Access Token Lifetime ......................11
3.2. Access Token ..............................................11
3.3. Refresh Token .............................................11
3.4. Authorization "code" ......................................12
3.5. Redirect URI ..............................................13
3.6. "state" Parameter .........................................13
3.7. Client Identifier .........................................13
4. Threat Model ...................................................15
4.1. Clients ...................................................16
4.1.1. Threat: Obtaining Client Secrets ...................16
4.1.2. Threat: Obtaining Refresh Tokens ...................17
4.1.3. Threat: Obtaining Access Tokens ....................19
4.1.4. Threat: End-User Credentials Phished Using
Compromised or Embedded Browser ....................19
4.1.5. Threat: Open Redirectors on Client .................20
4.2. Authorization Endpoint ....................................21
4.2.1. Threat: Password Phishing by Counterfeit
Authorization Server ...............................21
4.2.2. Threat: User Unintentionally Grants Too
Much Access Scope ..................................21
4.2.3. Threat: Malicious Client Obtains Existing
Authorization by Fraud .............................22
4.2.4. Threat: Open Redirector ............................22
4.3. Token Endpoint ............................................23
4.3.1. Threat: Eavesdropping Access Tokens ................23
4.3.2. Threat: Obtaining Access Tokens from
Authorization Server Database ......................23
4.3.3. Threat: Disclosure of Client Credentials
during Transmission ................................23
4.3.4. Threat: Obtaining Client Secret from
Authorization Server Database ......................24
4.3.5. Threat: Obtaining Client Secret by Online Guessing .24
4.4. Obtaining Authorization ...................................25
4.4.1. Authorization "code" ...............................25
4.4.1.1. Threat: Eavesdropping or Leaking
Authorization "codes" .....................25
4.4.1.2. Threat: Obtaining Authorization "codes"
from Authorization Server Database ........26
4.4.1.3. Threat: Online Guessing of
Authorization "codes" .....................27
4.4.1.4. Threat: Malicious Client Obtains
Authorization .............................27
4.4.1.5. Threat: Authorization "code" Phishing .....29
4.4.1.6. Threat: User Session Impersonation ........29
4.4.1.7. Threat: Authorization "code" Leakage
through Counterfeit Client ................30
4.4.1.8. Threat: CSRF Attack against redirect-uri ..32
4.4.1.9. Threat: Clickjacking Attack against
Authorization .............................33
4.4.1.10. Threat: Resource Owner Impersonation .....33
4.4.1.11. Threat: DoS Attacks That Exhaust
Resources ................................34
4.4.1.12. Threat: DoS Using Manufactured
Authorization "codes" ....................35
4.4.1.13. Threat: Code Substitution (OAuth Login) ..36
4.4.2. Implicit Grant .....................................37
4.4.2.1. Threat: Access Token Leak in
Transport/Endpoints .......................37
4.4.2.2. Threat: Access Token Leak in
Browser History ...........................38
4.4.2.3. Threat: Malicious Client Obtains
Authorization .............................38
4.4.2.4. Threat: Manipulation of Scripts ...........38
4.4.2.5. Threat: CSRF Attack against redirect-uri ..39
4.4.2.6. Threat: Token Substitution (OAuth Login) ..39
4.4.3. Resource Owner Password Credentials ................40
4.4.3.1. Threat: Accidental Exposure of
Passwords at Client Site ..................41
4.4.3.2. Threat: Client Obtains Scopes
without End-User Authorization ............42
4.4.3.3. Threat: Client Obtains Refresh
Token through Automatic Authorization .....42
4.4.3.4. Threat: Obtaining User Passwords
on Transport ..............................43
4.4.3.5. Threat: Obtaining User Passwords
from Authorization Server Database ........43
4.4.3.6. Threat: Online Guessing ...................43
4.4.4. Client Credentials .................................44
4.5. Refreshing an Access Token ................................44
4.5.1. Threat: Eavesdropping Refresh Tokens from
Authorization Server ...............................44
4.5.2. Threat: Obtaining Refresh Token from
Authorization Server Database ......................44
4.5.3. Threat: Obtaining Refresh Token by Online
Guessing ...........................................45
4.5.4. Threat: Refresh Token Phishing by
Counterfeit Authorization Server ...................45
4.6. Accessing Protected Resources .............................46
4.6.1. Threat: Eavesdropping Access Tokens on Transport ...46
4.6.2. Threat: Replay of Authorized Resource
Server Requests ....................................46
4.6.3. Threat: Guessing Access Tokens .....................46
4.6.4. Threat: Access Token Phishing by
Counterfeit Resource Server ........................47
4.6.5. Threat: Abuse of Token by Legitimate
Resource Server or Client ..........................48
4.6.6. Threat: Leak of Confidential Data in HTTP Proxies ..48
4.6.7. Threat: Token Leakage via Log Files and
HTTP Referrers .....................................48
5. Security Considerations ........................................49
5.1. General ...................................................49
5.1.1. Ensure Confidentiality of Requests .................49
5.1.2. Utilize Server Authentication ......................50
5.1.3. Always Keep the Resource Owner Informed ............50
5.1.4. Credentials ........................................51
5.1.4.1. Enforce Credential Storage
Protection Best Practices .................51
5.1.4.2. Online Attacks on Secrets .................52
5.1.5. Tokens (Access, Refresh, Code) .....................53
5.1.5.1. Limit Token Scope .........................53
5.1.5.2. Determine Expiration Time .................54
5.1.5.3. Use Short Expiration Time .................54
5.1.5.4. Limit Number of Usages or One-Time Usage ..55
5.1.5.5. Bind Tokens to a Particular
Resource Server (Audience) ................55
5.1.5.6. Use Endpoint Address as Token Audience ....56
5.1.5.7. Use Explicitly Defined Scopes for
Audience and Tokens .......................56
5.1.5.8. Bind Token to Client id ...................56
5.1.5.9. Sign Self-Contained Tokens ................56
5.1.5.10. Encrypt Token Content ....................56
5.1.5.11. Adopt a Standard Assertion Format ........57
5.1.6. Access Tokens ......................................57
5.2. Authorization Server ......................................57
5.2.1. Authorization "codes" ..............................57
5.2.1.1. Automatic Revocation of Derived
Tokens If Abuse Is Detected ...............57
5.2.2. Refresh Tokens .....................................57
5.2.2.1. Restricted Issuance of Refresh Tokens .....57
5.2.2.2. Binding of Refresh Token to "client_id" ...58
5.2.2.3. Refresh Token Rotation ....................58
5.2.2.4. Revocation of Refresh Tokens ..............58
5.2.2.5. Device Identification .....................59
5.2.2.6. X-FRAME-OPTIONS Header ....................59
5.2.3. Client Authentication and Authorization ............59
5.2.3.1. Don't Issue Secrets to Clients with
Inappropriate Security Policy .............60
5.2.3.2. Require User Consent for Public
Clients without Secret ....................60
5.2.3.3. Issue a "client_id" Only in
Combination with "redirect_uri" ...........61
5.2.3.4. Issue Installation-Specific Client
Secrets ...................................61
5.2.3.5. Validate Pre-Registered "redirect_uri" ....62
5.2.3.6. Revoke Client Secrets .....................63
5.2.3.7. Use Strong Client Authentication
(e.g., client_assertion/client_token) .....63
5.2.4. End-User Authorization .............................63
5.2.4.1. Automatic Processing of Repeated
Authorizations Requires Client Validation .63
5.2.4.2. Informed Decisions Based on Transparency ..63
5.2.4.3. Validation of Client Properties by
End User ..................................64
5.2.4.4. Binding of Authorization "code" to
"client_id" ...............................64
5.2.4.5. Binding of Authorization "code" to
"redirect_uri" ............................64
5.3. Client App Security .......................................65
5.3.1. Don't Store Credentials in Code or
Resources Bundled with Software Packages ...........65
5.3.2. Use Standard Web Server Protection Measures
(for Config Files and Databases) ...................65
5.3.3. Store Secrets in Secure Storage ....................65
5.3.4. Utilize Device Lock to Prevent Unauthorized
Device Access ......................................66
5.3.5. Link the "state" Parameter to User Agent Session ...66
5.4. Resource Servers ..........................................66
5.4.1. Authorization Headers ..............................66
5.4.2. Authenticated Requests .............................67
5.4.3. Signed Requests ....................................67
5.5. A Word on User Interaction and User-Installed Apps ........68
6. Acknowledgements ...............................................69
7. References .....................................................69
7.1. Normative References ......................................69
7.2. Informative References ....................................69
This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 protocol [RFC6749]. It contains the following content:
このドキュメントでは、OAuth 2.0プロトコルの包括的な脅威モデル[RFC6749]に基づいて、OAuth仕様に加えて、OAuthのセキュリティに関する追加の考慮事項について説明します。次のコンテンツが含まれています。
o Documents any assumptions and scope considered when creating the threat model.
o 脅威モデルを作成するときに考慮されるすべての仮定と範囲を文書化します。
o Describes the security features built into the OAuth protocol and how they are intended to thwart attacks.
o OAuthプロトコルに組み込まれているセキュリティ機能と、それらが攻撃を阻止することを目的とした方法について説明します。
o Gives a comprehensive threat model for OAuth and describes the respective countermeasures to thwart those threats.
o OAuthの包括的な脅威モデルを示し、それらの脅威を阻止するためのそれぞれの対策を説明します。
Threats include any intentional attacks on OAuth tokens and resources protected by OAuth tokens, as well as security risks introduced if the proper security measures are not put in place. Threats are structured along the lines of the protocol structure to help development teams implement each part of the protocol securely, for example, all threats for granting access, or all threats for a particular grant type, or all threats for protecting the resource server.
脅威には、OAuthトークンおよびOAuthトークンによって保護されているリソースに対する意図的な攻撃のほか、適切なセキュリティ対策が講じられていない場合に発生するセキュリティリスクが含まれます。脅威は、プロトコル構造の線に沿って構造化されており、開発チームがプロトコルの各部分を安全に実装できるようにします。たとえば、アクセスを許可するためのすべての脅威、特定の許可タイプのすべての脅威、またはリソースサーバーを保護するためのすべての脅威などです。
Note: This document cannot assess the probability or the risk associated with a particular threat because those aspects strongly depend on the particular application and deployment OAuth is used to protect. Similarly, impacts are given on a rather abstract level. But the information given here may serve as a foundation for deployment-specific threat models. Implementors may refine and detail the abstract threat model in order to account for the specific properties of their deployment and to come up with a risk analysis. As this document is based on the base OAuth 2.0 specification, it does not consider proposed extensions such as client registration or discovery, many of which are still under discussion.
注：これらの側面は特定のアプリケーションに強く依存し、OAuthを使用して保護するため、このドキュメントでは特定の脅威に関連する確率またはリスクを評価できません。同様に、影響はかなり抽象的なレベルで与えられます。ただし、ここで提供される情報は、展開固有の脅威モデルの基礎として役立つ場合があります。実装者は、展開の特定のプロパティを説明し、リスク分析を行うために、抽象的な脅威モデルを改良および詳細化できます。このドキュメントは基本的なOAuth 2.0仕様に基づいているため、クライアントの登録や検出などの提案された拡張については考慮されていません。それらの多くはまだ議論中です。
This security considerations document only considers clients bound to a particular deployment as supported by [RFC6749]. Such deployments have the following characteristics:
このセキュリティに関する考慮事項のドキュメントでは、[RFC6749]でサポートされている特定の展開にバインドされているクライアントのみが考慮されます。このような展開には、次の特性があります。
o Resource server URLs are static and well-known at development time; authorization server URLs can be static or discovered.
o リソースサーバーのURLは静的で、開発時にはよく知られています。許可サーバーのURLは静的または検出可能です。
o Token scope values (e.g., applicable URLs and methods) are well-known at development time.
o トークンのスコープ値（適用可能なURLやメソッドなど）は、開発時にはよく知られています。
o Client registration is out of scope of the current core specification. Therefore, this document assumes a broad variety of options, from static registration during development time to dynamic registration at runtime.
o クライアントの登録は、現在のコア仕様の範囲外です。したがって、このドキュメントでは、開発時の静的登録から実行時の動的登録まで、さまざまなオプションを想定しています。
The following are considered out of scope:
以下は範囲外と見なされます。
o Communication between the authorization server and resource server.
o 承認サーバーとリソースサーバー間の通信。
o Token formats.
o トークンの形式。
o Except for the resource owner password credentials grant type (see [RFC6749], Section 4.3), the mechanism used by authorization servers to authenticate the user.
o リソース所有者パスワード資格情報付与タイプ（[RFC6749]、セクション4.3を参照）を除き、承認サーバーがユーザーを認証するために使用するメカニズム。
o Mechanism by which a user obtained an assertion and any resulting attacks mounted as a result of the assertion being false.
o ユーザーがアサーションを取得するメカニズムと、アサーションが偽の結果として発生するすべての攻撃。
o Clients not bound to a specific deployment: An example could be a mail client with support for contact list access via the portable contacts API (see [Portable-Contacts]). Such clients cannot be registered upfront with a particular deployment and should dynamically discover the URLs relevant for the OAuth protocol.
o 特定の展開にバインドされていないクライアント：例として、ポータブル連絡先API（[Portable-Contacts]を参照）を介した連絡先リストへのアクセスをサポートするメールクライアントがあります。このようなクライアントは、特定のデプロイメントで事前に登録できず、OAuthプロトコルに関連するURLを動的に検出する必要があります。
The following assumptions relate to an attacker and resources available to an attacker. It is assumed that:
次の想定は、攻撃者と攻撃者が利用できるリソースに関連しています。次のことを前提としています。
o the attacker has full access to the network between the client and authorization servers and the client and the resource server, respectively. The attacker may eavesdrop on any communications between those parties. He is not assumed to have access to communication between the authorization server and resource server.
o攻撃者は、クライアントサーバーと承認サーバー、およびクライアントサーバーとリソースサーバーの間のネットワークに完全にアクセスできます。攻撃者は、それらの当事者間の通信を盗聴する可能性があります。彼は、許可サーバーとリソース・サーバーの間の通信にアクセスできるとは想定されていません。
o an attacker has unlimited resources to mount an attack.
o 攻撃者は、攻撃を開始するための無制限のリソースを持っています。
o two of the three parties involved in the OAuth protocol may collude to mount an attack against the 3rd party. For example, the client and authorization server may be under control of an attacker and collude to trick a user to gain access to resources.
o OAuthプロトコルに関係する3つのパーティのうち2つが共謀して、サードパーティに対する攻撃を仕掛ける可能性があります。たとえば、クライアントと認証サーバーが攻撃者の制御下にあり、ユーザーをだましてリソースにアクセスさせるために共謀する可能性があります。
This section documents assumptions about the features, limitations, and design options of the different entities of an OAuth deployment along with the security-sensitive data elements managed by those entities. These assumptions are the foundation of the threat analysis.
このセクションでは、OAuthデプロイメントのさまざまなエンティティの機能、制限、設計オプションに関する前提条件と、それらのエンティティによって管理されるセキュリティ上重要なデータ要素について説明します。これらの前提は脅威分析の基礎です。
The OAuth protocol leaves deployments with a certain degree of freedom regarding how to implement and apply the standard. The core specification defines the core concepts of an authorization server and a resource server. Both servers can be implemented in the same server entity, or they may also be different entities. The latter is typically the case for multi-service providers with a single authentication and authorization system and is more typical in middleware architectures.
OAuthプロトコルは、標準を実装および適用する方法に関して、ある程度の自由度のあるデプロイメントを残します。コア仕様は、承認サーバーとリソースサーバーのコアコンセプトを定義しています。両方のサーバーを同じサーバーエンティティに実装することも、異なるエンティティにすることもできます。後者は通常、単一の認証および承認システムを持つマルチサービスプロバイダーの場合であり、ミドルウェアアーキテクチャではより一般的です。
The following data elements are stored or accessible on the authorization server:
次のデータ要素は、承認サーバーに格納されているか、アクセスできます。
o usernames and passwords
o ユーザー名とパスワード
o client ids and secrets
o クライアントIDとシークレット
o client-specific refresh tokens
o クライアント固有の更新トークン
o client-specific access tokens (in the case of handle-based design; see Section 3.1)
o クライアント固有のアクセストークン（ハンドルベースのデザインの場合。セクション3.1を参照）
o HTTPS certificate/key
o HTTPS証明書/キー
o per-authorization process (in the case of handle-based design; Section 3.1): "redirect_uri", "client_id", authorization "code"
o 承認ごとのプロセス（ハンドルベースのデザインの場合、セクション3.1）：「redirect_uri」、「client_id」、承認「コード」
The following data elements are stored or accessible on the resource server:
次のデータ要素は、リソースサーバーに格納またはアクセスできます。
o user data (out of scope)
o ユーザーデータ（範囲外）
o HTTPS certificate/key
o HTTPS証明書/キー
o either authorization server credentials (handle-based design; see Section 3.1) or authorization server shared secret/public key (assertion-based design; see Section 3.1)
o 承認サーバーの資格情報（ハンドルベースのデザイン。セクション3.1を参照）または承認サーバーの共有秘密/公開キー（アサーションベースのデザイン。セクション3.1を参照）
o access tokens (per request)
o アクセストークン（リクエストごと）
It is assumed that a resource server has no knowledge of refresh tokens, user passwords, or client secrets.
リソースサーバーが更新トークン、ユーザーパスワード、またはクライアントシークレットを認識していないことを前提としています。
In OAuth, a client is an application making protected resource requests on behalf of the resource owner and with its authorization. There are different types of clients with different implementation and security characteristics, such as web, user-agent-based, and native applications. A full definition of the different client types and profiles is given in [RFC6749], Section 2.1.
OAuthでは、クライアントは、リソースの所有者に代わって、その承認を得て、保護されたリソース要求を行うアプリケーションです。 Web、ユーザーエージェントベース、ネイティブアプリケーションなど、実装とセキュリティの特性が異なるさまざまなタイプのクライアントがあります。さまざまなクライアントタイプとプロファイルの完全な定義は、[RFC6749]のセクション2.1に記載されています。
The following data elements are stored or accessible on the client:
次のデータ要素は、クライアントに格納されているか、アクセス可能です。
o client id (and client secret or corresponding client credential)
o クライアントID（およびクライアントシークレットまたは対応するクライアント資格情報）
o one or more refresh tokens (persistent) and access tokens (transient) per end user or other security-context or delegation context
o エンドユーザーまたはその他のセキュリティコンテキストまたは委任コンテキストごとに1つ以上の更新トークン（永続的）およびアクセストークン（一時的）
o trusted certification authority (CA) certificates (HTTPS)
o 信頼された証明機関（CA）証明書（HTTPS）
o per-authorization process: "redirect_uri", authorization "code"
o 承認ごとのプロセス：「redirect_uri」、承認「コード」
These are some of the security features that have been built into the OAuth 2.0 protocol to mitigate attacks and security issues.
これらは、攻撃とセキュリティの問題を軽減するためにOAuth 2.0プロトコルに組み込まれているセキュリティ機能の一部です。
OAuth makes extensive use of many kinds of tokens (access tokens, refresh tokens, authorization "codes"). The information content of a token can be represented in two ways, as follows:
OAuthは、さまざまな種類のトークン（アクセストークン、更新トークン、認証「コード」）を幅広く使用します。トークンの情報内容は、次の2つの方法で表すことができます。
Handle (or artifact) A 'handle' is a reference to some internal data structure within the authorization server; the internal data structure contains the attributes of the token, such as user id (UID), scope, etc. Handles enable simple revocation and do not require cryptographic mechanisms to protect token content from being modified. On the other hand, handles require communication between the issuing and consuming entity (e.g., the authorization server and resource server) in order to validate the token and obtain token-bound data. This communication might have a negative impact on performance and scalability if both entities reside on different systems. Handles are therefore typically used if the issuing and consuming entity are the same. A 'handle' token is often referred to as an 'opaque' token because the resource server does not need to be able to interpret the token directly; it simply uses the token.
ハンドル（またはアーティファクト）「ハンドル」は、承認サーバー内のいくつかの内部データ構造への参照です。内部データ構造には、ユーザーID（UID）、スコープなどのトークンの属性が含まれます。ハンドルは単純な失効を可能にし、トークンのコンテンツが変更されるのを防ぐための暗号メカニズムを必要としません。一方、ハンドルは、トークンを検証してトークンにバインドされたデータを取得するために、発行エンティティと消費エンティティ（承認サーバーとリソースサーバーなど）間の通信を必要とします。この通信は、両方のエンティティが異なるシステムに存在する場合、パフォーマンスとスケーラビリティに悪影響を及ぼす可能性があります。したがって、ハンドルは通常、発行エンティティと消費エンティティが同じ場合に使用されます。リソースサーバーがトークンを直接解釈できる必要がないため、「ハンドル」トークンは「不透明」トークンと呼ばれることがよくあります。単にトークンを使用します。
Assertion (aka self-contained token) An assertion is a parseable token. An assertion typically has a duration, has an audience, and is digitally signed in order to ensure data integrity and origin authentication. It contains information about the user and the client. Examples of assertion formats are Security Assertion Markup Language (SAML) assertions [OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120]. Assertions can typically be directly validated and used by a resource server without interactions with the authorization server. This results in better performance and scalability in deployments where the issuing and consuming entities reside on different systems. Implementing token revocation is more difficult with assertions than with handles.
アサーション（別名自己完結型トークン）アサーションは解析可能なトークンです。アサーションには通常、期間があり、オーディエンスがあり、データの整合性と送信元の認証を保証するためにデジタル署名されています。ユーザーとクライアントに関する情報が含まれています。アサーション形式の例は、セキュリティアサーションマークアップ言語（SAML）アサーション[OASIS.saml-core-2.0-os]およびKerberosチケット[RFC4120]です。アサーションは通常、承認サーバーと対話せずにリソースサーバーによって直接検証および使用できます。これにより、発行エンティティと消費エンティティが異なるシステムに存在する展開でのパフォーマンスとスケーラビリティが向上します。トークン失効の実装は、ハンドルよりもアサーションの方が困難です。
Tokens can be used in two ways to invoke requests on resource servers, as follows:
トークンは、次のように、リソースサーバーで要求を呼び出す2つの方法で使用できます。
bearer token A 'bearer token' is a token that can be used by any client who has received the token (e.g., [RFC6750]). Because mere possession is enough to use the token, it is important that communication between endpoints be secured to ensure that only authorized endpoints may capture the token. The bearer token is convenient for client applications, as it does not require them to do anything to use them (such as a proof of identity). Bearer tokens have similar characteristics to web single-sign-on (SSO) cookies used in browsers.
ベアラートークン「ベアラートークン」は、トークンを受け取った任意のクライアントが使用できるトークンです（例：[RFC6750]）。トークンを使用するには、所有するだけで十分なので、エンドポイント間の通信を保護して、承認されたエンドポイントのみがトークンを取得できるようにすることが重要です。ベアラートークンは、それを使用するために何もする必要がないため（IDの証明など）、クライアントアプリケーションにとって便利です。ベアラートークンには、ブラウザーで使用されるWebシングルサインオン（SSO）Cookieと同様の特性があります。
proof token A 'proof token' is a token that can only be used by a specific client. Each use of the token requires the client to perform some action that proves that it is the authorized user of the token. Examples of this are MAC-type access tokens, which require the client to digitally sign the resource request with a secret corresponding to the particular token sent with the request (e.g., [OAuth-HTTP-MAC]).
証明トークン「証明トークン」は、特定のクライアントのみが使用できるトークンです。トークンを使用するたびに、クライアントは、それがトークンの承認されたユーザーであることを証明する何らかのアクションを実行する必要があります。この例はMACタイプのアクセストークンです。クライアントは、リクエストで送信された特定のトークンに対応するシークレット（[OAuth-HTTP-MAC]など）でリソースリクエストにデジタル署名する必要があります。
A scope represents the access authorization associated with a particular token with respect to resource servers, resources, and methods on those resources. Scopes are the OAuth way to explicitly manage the power associated with an access token. A scope can be controlled by the authorization server and/or the end user in order to limit access to resources for OAuth clients that these parties deem less secure or trustworthy. Optionally, the client can request the scope to apply to the token but only for a lesser scope than would otherwise be granted, e.g., to reduce the potential impact if this token is sent over non-secure channels. A scope is typically complemented by a restriction on a token's lifetime.
スコープは、リソースサーバー、リソース、およびそれらのリソースのメソッドに関する特定のトークンに関連付けられたアクセス許可を表します。スコープは、アクセストークンに関連付けられた権限を明示的に管理するOAuthの方法です。許可サーバーやエンドユーザーがスコープを制御して、これらの当事者が安全性や信頼性が低いと見なすOAuthクライアントのリソースへのアクセスを制限することができます。必要に応じて、クライアントはスコープにトークンに適用するよう要求できますが、このトークンが安全でないチャネルを介して送信される場合の潜在的な影響を軽減するためなど、他の場合に許可されるスコープよりも小さいスコープに対してのみ適用できます。スコープは通常、トークンの有効期間の制限によって補完されます。
The protocol parameter "expires_in" allows an authorization server (based on its policies or on behalf of the end user) to limit the lifetime of an access token and to pass this information to the client. This mechanism can be used to issue short-lived tokens to OAuth clients that the authorization server deems less secure, or where sending tokens over non-secure channels.
プロトコルパラメータ「expires_in」を使用すると、認証サーバー（ポリシーに基づくか、エンドユーザーに代わって）がアクセストークンの有効期間を制限し、この情報をクライアントに渡すことができます。このメカニズムを使用して、許可サーバーが安全性が低いと見なしたOAuthクライアントに有効期間が短いトークンを発行したり、トークンを安全でないチャネルで送信したりできます。
An access token is used by a client to access a resource. Access tokens typically have short life spans (minutes or hours) that cover typical session lifetimes. An access token may be refreshed through the use of a refresh token. The short lifespan of an access token, in combination with the usage of refresh tokens, enables the possibility of passive revocation of access authorization on the expiry of the current access token.
アクセストークンは、クライアントがリソースにアクセスするために使用されます。通常、アクセストークンのライフスパンは短く（分または時間）、通常のセッションライフタイムをカバーしています。アクセストークンは、リフレッシュトークンを使用してリフレッシュできます。アクセストークンの有効期間が短いため、リフレッシュトークンを使用すると、現在のアクセストークンの有効期限が切れたときに、アクセス許可を受動的に取り消すことができます。
A refresh token represents a long-lasting authorization of a certain client to access resources on behalf of a resource owner. Such tokens are exchanged between the client and authorization server only. Clients use this kind of token to obtain ("refresh") new access tokens used for resource server invocations.
更新トークンは、リソース所有者に代わってリソースにアクセスする特定のクライアントの長期にわたる承認を表します。このようなトークンは、クライアントと許可サーバーの間でのみ交換されます。クライアントはこの種類のトークンを使用して、リソースサーバーの呼び出しに使用される新しいアクセストークンを取得（ "更新"）します。
A refresh token, coupled with a short access token lifetime, can be used to grant longer access to resources without involving end-user authorization. This offers an advantage where resource servers and authorization servers are not the same entity, e.g., in a distributed environment, as the refresh token is always exchanged at the authorization server. The authorization server can revoke the refresh token at any time, causing the granted access to be revoked once the current access token expires. Because of this, a short access token lifetime is important if timely revocation is a high priority.
更新トークンを短いアクセストークンの有効期間と組み合わせて使用すると、エンドユーザーの承認を行うことなく、リソースへのより長いアクセスを許可できます。これにより、リソースサーバーと承認サーバーが同じエンティティではない場合（たとえば、分散環境では）、更新トークンが常に承認サーバーで交換されるため、利点があります。承認サーバーはいつでも更新トークンを取り消すことができるため、現在のアクセストークンの有効期限が切れると、許可されたアクセスが取り消されます。このため、タイムリーな失効を優先する場合は、アクセストークンの有効期間を短くすることが重要です。
The refresh token is also a secret bound to the client identifier and client instance that originally requested the authorization; the refresh token also represents the original resource owner grant. This is ensured by the authorization process as follows:
更新トークンは、最初に承認を要求したクライアント識別子とクライアントインスタンスにバインドされたシークレットでもあります。更新トークンは、元のリソース所有者の付与も表します。これは、次の承認プロセスによって保証されます。
1. The resource owner and user agent safely deliver the authorization "code" to the client instance in the first place.
1. リソース所有者とユーザーエージェントは、最初に認証「コード」をクライアントインスタンスに安全に配信します。
2. The client uses it immediately in secure transport-level communications to the authorization server and then securely stores the long-lived refresh token.
2. クライアントは、認証サーバーへの安全なトランスポートレベルの通信ですぐにそれを使用し、長期間有効な更新トークンを安全に保存します。
3. The client always uses the refresh token in secure transport-level communications to the authorization server to get an access token (and optionally roll over the refresh token).
3. クライアントは常に、承認サーバーへの安全なトランスポートレベルの通信で更新トークンを使用して、アクセストークンを取得します（オプションで更新トークンをロールオーバーします）。
So, as long as the confidentiality of the particular token can be ensured by the client, a refresh token can also be used as an alternative means to authenticate the client instance itself.
したがって、クライアントが特定のトークンの機密性を確保できる限り、クライアントインスタンス自体を認証するための代替手段として、リフレッシュトークンを使用することもできます。
An authorization "code" represents the intermediate result of a successful end-user authorization process and is used by the client to obtain access and refresh tokens. Authorization "codes" are sent to the client's redirect URI instead of tokens for two purposes:
承認 "コード"は、成功したエンドユーザー承認プロセスの中間結果を表し、クライアントがアクセストークンと更新トークンを取得するために使用されます。承認「コード」は、次の2つの目的で、トークンの代わりにクライアントのリダイレクトURIに送信されます。
1. Browser-based flows expose protocol parameters to potential attackers via URI query parameters (HTTP referrer), the browser cache, or log file entries, and could be replayed. In order to reduce this threat, short-lived authorization "codes" are passed instead of tokens and exchanged for tokens over a more secure direct connection between the client and the authorization server.
1. ブラウザベースのフローは、URIクエリパラメータ（HTTPリファラー）、ブラウザキャッシュ、またはログファイルエントリを介してプロトコルパラメータを潜在的な攻撃者に公開し、再生される可能性があります。この脅威を減らすために、トークンの代わりに有効期間の短い認証「コード」が渡され、クライアントと認証サーバー間のより安全な直接接続を介してトークンと交換されます。
2. It is much simpler to authenticate clients during the direct request between the client and the authorization server than in the context of the indirect authorization request. The latter would require digital signatures.
2. クライアントと許可サーバー間の直接要求中にクライアントを認証する方が、間接許可要求の場合よりもはるかに簡単です。後者にはデジタル署名が必要です。
A redirect URI helps to detect malicious clients and prevents phishing attacks from clients attempting to trick the user into believing the phisher is the client. The value of the actual redirect URI used in the authorization request has to be presented and is verified when an authorization "code" is exchanged for tokens. This helps to prevent attacks where the authorization "code" is revealed through redirectors and counterfeit web application clients. The authorization server should require public clients and confidential clients using the implicit grant type to pre-register their redirect URIs and validate against the registered redirect URI in the authorization request.
リダイレクトURIは、悪意のあるクライアントを検出するのに役立ち、フィッシング詐欺師がクライアントであるとユーザーをだましてユーザーをだまそうとするクライアントからのフィッシング攻撃を防ぎます。承認リクエストで使用される実際のリダイレクトURIの値は提示する必要があり、承認「コード」がトークンと交換されるときに検証されます。これにより、リダイレクターや偽のWebアプリケーションクライアントを介して認証「コード」が明らかになる攻撃を防ぐことができます。承認サーバーは、暗黙の付与タイプを使用してパブリッククライアントと機密クライアントにリダイレクトURIを事前登録し、承認リクエストで登録済みのリダイレクトURIに対して検証する必要があります。
The "state" parameter is used to link requests and callbacks to prevent cross-site request forgery attacks (see Section 4.4.1.8) where an attacker authorizes access to his own resources and then tricks a user into following a redirect with the attacker's token. This parameter should bind to the authenticated state in a user agent and, as per the core OAuth spec, the user agent must be capable of keeping it in a location accessible only by the client and user agent, i.e., protected by same-origin policy.
「state」パラメータは、リクエストとコールバックをリンクしてクロスサイトリクエストフォージェリ攻撃（4.4.1.8を参照）を防止するために使用されます。攻撃者は自分のリソースへのアクセスを許可し、攻撃者のトークンを使用してリダイレクトするようにユーザーを騙します。このパラメーターは、ユーザーエージェントの認証済み状態にバインドする必要があります。コアOAuth仕様に従って、ユーザーエージェントは、クライアントとユーザーエージェントのみがアクセスできる場所、つまり同一生成元ポリシーで保護された場所にそれを保持できる必要があります。 。
Authentication protocols have typically not taken into account the identity of the software component acting on behalf of the end user. OAuth does this in order to increase the security level in delegated authorization scenarios and because the client will be able to act without the user being present.
通常、認証プロトコルでは、エンドユーザーに代わって機能するソフトウェアコンポーネントのIDは考慮されていません。 OAuthは、委任された承認シナリオでセキュリティレベルを向上させるために、ユーザーが存在しなくてもクライアントが動作できるようにするためにこれを行います。
OAuth uses the client identifier to collate associated requests to the same originator, such as
OAuthは、クライアント識別子を使用して、関連する要求を同じ発信者に照合します。
o a particular end-user authorization process and the corresponding request on the token's endpoint to exchange the authorization "code" for tokens, or
o 特定のエンドユーザー認証プロセスと、トークンの認証「コード」を交換するためのトークンのエンドポイント上の対応する要求、または
o the initial authorization and issuance of a token by an end user to a particular client, and subsequent requests by this client to obtain tokens without user consent (automatic processing of repeated authorizations)
o エンドユーザーによる特定のクライアントへの最初の承認とトークンの発行、およびユーザーの同意なしにトークンを取得するためのこのクライアントによる後続の要求（繰り返し承認の自動処理）
This identifier may also be used by the authorization server to display relevant registration information to a user when requesting consent for a scope requested by a particular client. The client identifier may be used to limit the number of requests for a particular client or to charge the client per request. It may furthermore be useful to differentiate access by different clients, e.g., in server log files.
この識別子は、特定のクライアントによって要求されたスコープの同意を要求するときに、関連する登録情報をユーザーに表示するために承認サーバーによって使用される場合もあります。クライアント識別子を使用して、特定のクライアントに対する要求の数を制限したり、要求ごとにクライアントに課金したりできます。さらに、たとえばサーバーログファイルで、異なるクライアントによるアクセスを区別することは有用かもしれません。
OAuth defines two client types, confidential and public, based on their ability to authenticate with the authorization server (i.e., ability to maintain the confidentiality of their client credentials). Confidential clients are capable of maintaining the confidentiality of client credentials (i.e., a client secret associated with the client identifier) or capable of secure client authentication using other means, such as a client assertion (e.g., SAML) or key cryptography. The latter is considered more secure.
OAuthは、承認サーバーで認証する能力（クライアントの資格情報の機密性を維持する能力）に基づいて、機密と公開の2つのクライアントタイプを定義します。機密クライアントは、クライアント資格情報（つまり、クライアント識別子に関連付けられたクライアントシークレット）の機密性を維持したり、クライアントアサーション（SAMLなど）やキー暗号化などの他の手段を使用した安全なクライアント認証を行うことができます。後者はより安全であると考えられています。
The authorization server should determine whether the client is capable of keeping its secret confidential or using secure authentication. Alternatively, the end user can verify the identity of the client, e.g., by only installing trusted applications. The redirect URI can be used to prevent the delivery of credentials to a counterfeit client after obtaining end-user authorization in some cases but can't be used to verify the client identifier.
認可サーバーは、クライアントがその秘密を機密に保つことができるか、または安全な認証を使用できるかを決定する必要があります。または、エンドユーザーは、信頼できるアプリケーションをインストールするだけで、クライアントの身元を確認できます。リダイレクトURIは、場合によってはエンドユーザーの承認を得た後、偽造クライアントへの資格情報の配信を防ぐために使用できますが、クライアント識別子の検証には使用できません。
Clients can be categorized as follows based on the client type, profile (e.g., native vs. web application; see [RFC6749], Section 9), and deployment model:
クライアントは、クライアントの種類、プロファイル（ネイティブアプリケーションとWebアプリケーションなど。[RFC6749]のセクション9を参照）、および導入モデルに基づいて、次のように分類できます。
Deployment-independent "client_id" with pre-registered "redirect_uri" and without "client_secret" Such an identifier is used by multiple installations of the same software package. The identifier of such a client can only be validated with the help of the end-user. This is a viable option for native applications in order to identify the client for the purpose of displaying meta information about the client to the user and to differentiate clients in log files. Revocation of the rights associated with such a client identifier will affect ALL deployments of the respective software.
事前に登録された「redirect_uri」があり、「client_secret」がない、配備に依存しない「client_id」このような識別子は、同じソフトウェアパッケージの複数のインストールで使用されます。このようなクライアントの識別子は、エンドユーザーの助けを借りてのみ検証できます。これは、クライアントに関するメタ情報をユーザーに表示する目的でクライアントを識別し、ログファイルでクライアントを区別するために、ネイティブアプリケーションにとって実行可能なオプションです。そのようなクライアント識別子に関連付けられた権利の取り消しは、それぞれのソフトウェアのすべての展開に影響します。
Deployment-independent "client_id" with pre-registered "redirect_uri" and with "client_secret" This is an option for native applications only, since web applications would require different redirect URIs. This category is not advisable because the client secret cannot be protected appropriately (see Section 4.1.1). Due to its security weaknesses, such client identities have the same trust level as deployment-independent clients without secrets. Revocation will affect ALL deployments.
事前登録済みの「redirect_uri」と「client_secret」を使用したデプロイメントに依存しない「client_id」これは、Webアプリケーションが異なるリダイレクトURIを必要とするため、ネイティブアプリケーション専用のオプションです。クライアントシークレットを適切に保護できないため、このカテゴリはお勧めできません（セクション4.1.1を参照）。セキュリティ上の弱点があるため、このようなクライアントIDには、秘密のない展開に依存しないクライアントと同じ信頼レベルがあります。取り消しはすべての展開に影響します。
Deployment-specific "client_id" with pre-registered "redirect_uri" and with "client_secret" The client registration process ensures the validation of the client's properties, such as redirect URI, web site URL, web site name, and contacts. Such a client identifier can be utilized for all relevant use cases cited above. This level can be achieved for web applications in combination with a manual or user-bound registration process. Achieving this level for native applications is much more difficult. Either the installation of the application is conducted by an administrator, who validates the client's authenticity, or the process from validating the application to the installation of the application on the device and the creation of the client credentials is controlled end-to-end by a single entity (e.g., application market provider). Revocation will affect a single deployment only.
事前登録された「redirect_uri」と「client_secret」を使用したデプロイメント固有の「client_id」クライアント登録プロセスにより、リダイレクトURI、WebサイトURL、Webサイト名、連絡先などのクライアントのプロパティの検証が保証されます。このようなクライアント識別子は、上記で引用されたすべての関連するユースケースに利用できます。このレベルは、手動またはユーザー向けの登録プロセスと組み合わせたWebアプリケーションで達成できます。ネイティブアプリケーションでこのレベルを達成することは、はるかに困難です。アプリケーションのインストールは、クライアントの信頼性を検証する管理者によって行われるか、アプリケーションの検証からデバイスへのアプリケーションのインストールおよびクライアント資格情報の作成までのプロセスが、エンドツーエンドで制御されます。単一のエンティティー（アプリケーション市場プロバイダーなど）。取り消しは、単一のデプロイメントにのみ影響します。
Deployment-specific "client_id" with "client_secret" without validated properties Such a client can be recognized by the authorization server in transactions with subsequent requests (e.g., authorization and token issuance, refresh token issuance, and access token refreshment). The authorization server cannot assure any property of the client to end users. Automatic processing of re-authorizations could be allowed as well. Such client credentials can be generated automatically without any validation of client properties, which makes it another option, especially for native applications. Revocation will affect a single deployment only.
検証されたプロパティのない "client_secret"を含むデプロイメント固有の "client_id"このようなクライアントは、後続の要求（承認とトークンの発行、更新トークンの発行、アクセストークンの更新など）とのトランザクションで承認サーバーによって認識されます。承認サーバーは、クライアントのプロパティをエンドユーザーに保証することはできません。再承認の自動処理も許可できます。このようなクライアント資格情報は、クライアントプロパティを検証せずに自動的に生成できるため、特にネイティブアプリケーションでは、別のオプションになります。取り消しは、単一のデプロイメントにのみ影響します。
This section gives a comprehensive threat model of OAuth 2.0. Threats are grouped first by attacks directed against an OAuth component, which are the client, authorization server, and resource server. Subsequently, they are grouped by flow, e.g., obtain token or access protected resources. Every countermeasure description refers to a detailed description in Section 5.
このセクションでは、OAuth 2.0の包括的な脅威モデルを示します。脅威は、クライアント、承認サーバー、リソースサーバーであるOAuthコンポーネントに対する攻撃によって最初にグループ化されます。その後、それらはフローごとにグループ化されます。たとえば、トークンを取得したり、保護されたリソースにアクセスしたりします。すべての対策の説明は、セクション5の詳細な説明を参照しています。
This section describes possible threats directed to OAuth clients.
このセクションでは、OAuthクライアントに向けられる可能性のある脅威について説明します。
The attacker could try to get access to the secret of a particular client in order to:
攻撃者は、次の目的で特定のクライアントのシークレットにアクセスしようとする可能性があります。
o replay its refresh tokens and authorization "codes", or
o 更新トークンと承認「コード」を再生する、または
o obtain tokens on behalf of the attacked client with the privileges of that "client_id" acting as an instance of the client.
o 攻撃されたクライアントに代わって、クライアントのインスタンスとして機能する「client_id」の権限を持つトークンを取得します。
The resulting impact would be the following:
結果として生じる影響は次のとおりです。
o Client authentication of access to the authorization server can be bypassed.
o 許可サーバーへのアクセスのクライアント認証はバイパスできます。
o Stolen refresh tokens or authorization "codes" can be replayed.
o 盗まれた更新トークンまたは認証「コード」を再生できます。
Depending on the client category, the following attacks could be utilized to obtain the client secret.
クライアントのカテゴリに応じて、次の攻撃がクライアントシークレットを取得するために利用される可能性があります。
Attack: Obtain Secret From Source Code or Binary:
攻撃：ソースコードまたはバイナリからシークレットを取得します。
This applies for all client types. For open source projects, secrets can be extracted directly from source code in their public repositories. Secrets can be extracted from application binaries just as easily when the published source is not available to the attacker. Even if an application takes significant measures to obfuscate secrets in their application distribution, one should consider that the secret can still be reverse-engineered by anyone with access to a complete functioning application bundle or binary.
これは、すべてのクライアントタイプに適用されます。オープンソースプロジェクトの場合、シークレットはパブリックリポジトリのソースコードから直接抽出できます。公開されたソースが攻撃者に利用できない場合と同じくらい簡単に、アプリケーションバイナリからシークレットを抽出できます。アプリケーションがアプリケーションディストリビューションのシークレットを難読化するために重要な対策を講じている場合でも、完全に機能しているアプリケーションバンドルまたはバイナリにアクセスできるユーザーであれば、シークレットをリバースエンジニアリングできることを考慮する必要があります。
Countermeasures:
対応策：
o Don't issue secrets to public clients or clients with inappropriate security policy (Section 5.2.3.1).
o パブリッククライアントまたは不適切なセキュリティポリシーを持つクライアントに秘密を発行しないでください（セクション5.2.3.1）。
o Require user consent for public clients (Section 5.2.3.2).
o パブリッククライアントに対してユーザーの同意を要求する（セクション5.2.3.2）。
o Use deployment-specific client secrets (Section 5.2.3.4).
o デプロイメント固有のクライアントシークレットを使用します（セクション5.2.3.4）。
o Revoke client secrets (Section 5.2.3.6).
o クライアントシークレットを取り消す（セクション5.2.3.6）。
Attack: Obtain a Deployment-Specific Secret:
攻撃：展開固有のシークレットを取得します。
An attacker may try to obtain the secret from a client installation, either from a web site (web server) or a particular device (native application).
攻撃者は、Webサイト（Webサーバー）または特定のデバイス（ネイティブアプリケーション）から、クライアントインストールからシークレットを取得しようとする可能性があります。
Countermeasures:
対応策：
o Web server: Apply standard web server protection measures (for config files and databases) (see Section 5.3.2).
o Webサーバー：標準のWebサーバー保護対策を適用します（構成ファイルとデータベース用）（セクション5.3.2を参照）。
o Native applications: Store secrets in secure local storage (Section 5.3.3).
o ネイティブアプリケーション：シークレットを安全なローカルストレージに保存します（セクション5.3.3）。
o Revoke client secrets (Section 5.2.3.6).
o クライアントシークレットを取り消す（セクション5.2.3.6）。
Depending on the client type, there are different ways that refresh tokens may be revealed to an attacker. The following sub-sections give a more detailed description of the different attacks with respect to different client types and further specialized countermeasures. Before detailing those threats, here are some generally applicable countermeasures:
クライアントの種類に応じて、更新トークンを攻撃者に明らかにする方法がいくつかあります。次のサブセクションでは、さまざまなクライアントの種類と、さらに特殊な対策に関するさまざまな攻撃について詳しく説明します。これらの脅威の詳細を説明する前に、一般的に適用可能な対策をいくつか示します。
o The authorization server should validate the client id associated with the particular refresh token with every refresh request (Section 5.2.2.2).
o 承認サーバーは、すべての更新要求で特定の更新トークンに関連付けられたクライアントIDを検証する必要があります（セクション5.2.2.2）。
o Limit token scope (Section 5.1.5.1).
o トークンのスコープを制限します（セクション5.1.5.1）。
o Revoke refresh tokens (Section 5.2.2.4).
o 更新トークンを取り消します（セクション5.2.2.4）。
o Revoke client secrets (Section 5.2.3.6).
o クライアントシークレットを取り消す（セクション5.2.3.6）。
o Refresh tokens can automatically be replaced in order to detect unauthorized token usage by another party (see "Refresh Token Rotation", Section 5.2.2.3).
o リフレッシュトークンは、別のパーティによる不正なトークンの使用を検出するために自動的に置き換えることができます（「リフレッシュトークンのローテーション」のセクション5.2.2.3を参照）。
Attack: Obtain Refresh Token from Web Application:
攻撃：Webアプリケーションから更新トークンを取得します。
An attacker may obtain the refresh tokens issued to a web application by way of overcoming the web server's security controls.
攻撃者は、Webサーバーのセキュリティ制御を克服する方法で、Webアプリケーションに発行された更新トークンを取得する可能性があります。
Impact: Since a web application manages the user accounts of a certain site, such an attack would result in an exposure of all refresh tokens on that site to the attacker.
影響：Webアプリケーションは特定のサイトのユーザーアカウントを管理するため、このような攻撃により、そのサイトのすべての更新トークンが攻撃者に公開されます。
Countermeasures:
対応策：
o Standard web server protection measures (Section 5.3.2).
o 標準のWebサーバー保護対策（セクション5.3.2）。
o Use strong client authentication (e.g., client_assertion/ client_token) so the attacker cannot obtain the client secret required to exchange the tokens (Section 5.2.3.7).
o 強力なクライアント認証（client_assertion / client_tokenなど）を使用して、攻撃者がトークンの交換に必要なクライアントシークレットを取得できないようにします（セクション5.2.3.7）。
Attack: Obtain Refresh Token from Native Clients:
攻撃：ネイティブクライアントから更新トークンを取得します。
On native clients, leakage of a refresh token typically affects a single user only.
ネイティブクライアントでは、更新トークンの漏洩は通常、単一のユーザーにのみ影響します。
Read from local file system: The attacker could try to get file system access on the device and read the refresh tokens. The attacker could utilize a malicious application for that purpose.
ローカルファイルシステムから読み取る：攻撃者は、デバイス上のファイルシステムアクセスを取得し、更新トークンを読み取る可能性があります。攻撃者はその目的で悪意のあるアプリケーションを利用する可能性があります。
Countermeasures:
対応策：
o Store secrets in secure storage (Section 5.3.3).
o シークレットを安全なストレージに保存します（セクション5.3.3）。
o Utilize device lock to prevent unauthorized device access (Section 5.3.4).
o デバイスロックを利用して、不正なデバイスアクセスを防止します（セクション5.3.4）。
Attack: Steal Device:
攻撃：デバイスを盗む：
The host device (e.g., mobile phone) may be stolen. In that case, the attacker gets access to all applications under the identity of the legitimate user.
ホストデバイス（携帯電話など）が盗まれる可能性があります。その場合、攻撃者は正当なユーザーのIDですべてのアプリケーションにアクセスできます。
Countermeasures:
対応策：
o Utilize device lock to prevent unauthorized device access (Section 5.3.4).
o デバイスロックを利用して、不正なデバイスアクセスを防止します（セクション5.3.4）。
o Where a user knows the device has been stolen, they can revoke the affected tokens (Section 5.2.2.4).
o ユーザーは、デバイスが盗まれたことを知っている場合、影響を受けるトークンを取り消すことができます（セクション5.2.2.4）。
Attack: Clone Device:
攻撃：デバイスのクローン：
All device data and applications are copied to another device. Applications are used as-is on the target device.
すべてのデバイスデータとアプリケーションが別のデバイスにコピーされます。アプリケーションは、ターゲットデバイス上でそのまま使用されます。
Countermeasures:
対応策：
o Utilize device lock to prevent unauthorized device access (Section 5.3.4).
o デバイスロックを利用して、不正なデバイスアクセスを防止します（セクション5.3.4）。
o Combine refresh token request with device identification (Section 5.2.2.5).
o 更新トークン要求をデバイスIDと組み合わせます（セクション5.2.2.5）。
o Refresh token rotation (Section 5.2.2.3).
o トークンのローテーションを更新します（セクション5.2.2.3）。
o Where a user knows the device has been cloned, they can use refresh token revocation (Section 5.2.2.4).
o ユーザーは、デバイスのクローンが作成されていることを知っている場合、更新トークンの取り消しを使用できます（セクション5.2.2.4）。
Depending on the client type, there are different ways that access tokens may be revealed to an attacker. Access tokens could be stolen from the device if the application stores them in a storage device that is accessible to other applications.
クライアントの種類に応じて、アクセストークンが攻撃者に明らかにされる可能性があるさまざまな方法があります。アプリケーションが他のアプリケーションからアクセス可能なストレージデバイスにアクセストークンを保存すると、デバイスからアクセストークンが盗まれる可能性があります。
Impact: Where the token is a bearer token and no additional mechanism is used to identify the client, the attacker can access all resources associated with the token and its scope.
影響：トークンが無記名トークンであり、クライアントを識別するために追加のメカニズムが使用されていない場合、攻撃者はトークンとそのスコープに関連付けられているすべてのリソースにアクセスできます。
Countermeasures:
対応策：
o Keep access tokens in transient memory and limit grants (Section 5.1.6).
o アクセストークンを一時メモリに保持し、付与を制限します（セクション5.1.6）。
o Limit token scope (Section 5.1.5.1).
o トークンのスコープを制限します（セクション5.1.5.1）。
o Keep access tokens in private memory or apply same protection means as for refresh tokens (Section 5.2.2).
o アクセストークンをプライベートメモリに保持するか、リフレッシュトークンと同じ保護手段を適用します（セクション5.2.2）。
o Keep access token lifetime short (Section 5.1.5.3).
o アクセストークンの有効期間を短くします（セクション5.1.5.3）。
4.1.4. Threat: End-User Credentials Phished Using Compromised or Embedded Browser
4.1.4. 脅威：エンドユーザーの資格情報が侵害されたブラウザーまたは埋め込みブラウザーを使用してフィッシング
A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user interface instead of allowing a trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g., Transport Layer Security (TLS) confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information to which it should not have access (e.g., UID/password).
悪意のあるアプリケーションは、エンドユーザーの承認プロセスで埋め込みブラウザーを誤用するか、信頼できるシステムのブラウザーに承認ユーザーインターフェイスを表示させる代わりに独自のユーザーインターフェイスを提示することで、エンドユーザーパスワードをフィッシングしようとする可能性があります。そうすることで、通常の視覚的な信頼メカニズムがバイパスされる可能性があります（トランスポート層セキュリティ（TLS）の確認、Webサイトのメカニズムなど）。組み込みまたは内部のクライアントアプリケーションユーザーインターフェイスを使用することにより、クライアントアプリケーションは、アクセスしてはならない追加情報（UID /パスワードなど）にアクセスできます。
Impact: If the client application or the communication is compromised, the user would not be aware of this, and all information in the authorization exchange, such as username and password, could be captured.
影響：クライアントアプリケーションまたは通信が危険にさらされている場合、ユーザーはこれに気付かず、ユーザー名やパスワードなどの認証交換のすべての情報が取得される可能性があります。
Countermeasures:
対応策：
o The OAuth flow is designed so that client applications never need to know user passwords. Client applications should avoid directly asking users for their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed.
o OAuthフローは、クライアントアプリケーションがユーザーパスワードを知る必要がないように設計されています。クライアントアプリケーションでは、ユーザーに直接資格情報を要求することは避けてください。さらに、OAuthは悪意のあるアプリケーションに対する保護を提供せず、インストールされているネイティブアプリケーションの信頼性はエンドユーザーのみが責任を負うため、エンドユーザーはフィッシング攻撃や信頼できるクライアントにのみアクセスするなどのベストプラクティスについて教育を受けることができます。
o Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way.
o クライアントアプリケーションは、ユーザーがアクセスできるアプリケーションマーケットで公開する前に検証できます。この検証はOAuthの範囲外ですが、クライアントアプリケーションがユーザー認証を適切な方法で処理することの検証を含めることができます。
o Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g., the system browser.
o クライアント開発者は、ユーザーから認証情報を直接収集するクライアントアプリケーションを作成するのではなく、このタスクを信頼できるシステムコンポーネント（システムブラウザーなど）に委任する必要があります。
An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. If the authorization server allows the client to register only part of the redirect URI, an attacker can use an open redirector operated by the client to construct a redirect URI that will pass the authorization server validation but will send the authorization "code" or access token to an endpoint under the control of the attacker.
オープンリダイレクターは、パラメーターを使用して、検証なしでパラメーター値で指定された場所にユーザーエージェントを自動的にリダイレクトするエンドポイントです。承認サーバーがクライアントにリダイレクトURIの一部のみの登録を許可している場合、攻撃者はクライアントが操作するオープンリダイレクターを使用して、承認サーバーの検証に合格するが承認「コード」またはアクセストークンを送信するリダイレクトURIを構築できます。攻撃者の制御下にあるエンドポイントに。
Impact: An attacker could gain access to authorization "codes" or access tokens.
影響：攻撃者は、認可「コード」またはアクセストークンにアクセスする可能性があります。
Countermeasures:
対応策：
o Require clients to register full redirect URI (Section 5.2.3.5).
o クライアントに完全なリダイレクトURIの登録を要求する（セクション5.2.3.5）。
OAuth makes no attempt to verify the authenticity of the authorization server. A hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise incorrect responses. This could be achieved using DNS or Address Resolution Protocol (ARP) spoofing. Wide deployment of OAuth and similar protocols may cause users to become inured to the practice of being redirected to web sites where they are asked to enter their passwords. If users are not careful to verify the authenticity of these web sites before entering their credentials, it will be possible for attackers to exploit this practice to steal users' passwords.
OAuthは、許可サーバーの信憑性の検証を試みません。敵対的な当事者は、クライアントの要求を傍受し、誤解を招く、またはその他の不正な応答を返すことで、これを利用できます。これは、DNSまたはアドレス解決プロトコル（ARP）スプーフィングを使用して実現できます。 OAuthや類似のプロトコルを幅広く展開すると、ユーザーは、パスワードの入力を求められるWebサイトにリダイレクトされる習慣に慣れることができない場合があります。ユーザーが資格情報を入力する前にこれらのWebサイトの信頼性を慎重に検証しない場合、攻撃者がこの手法を悪用してユーザーのパスワードを盗む可能性があります。
Countermeasures:
対応策：
o Authorization servers should consider such attacks when developing services based on OAuth and should require the use of transport-layer security for any requests where the authenticity of the authorization server or of request responses is an issue (see Section 5.1.2).
o 承認サーバーは、OAuthに基づいてサービスを開発するときにこのような攻撃を考慮し、承認サーバーまたは要求応答の信頼性が問題であるすべての要求に対してトランスポート層セキュリティの使用を要求する必要があります（セクション5.1.2を参照）。
o Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites.
o 承認サーバーは、フィッシング攻撃によってもたらされるリスクについてユーザーを教育し、ユーザーがサイトの信頼性を簡単に確認できるようにするメカニズムを提供する必要があります。
When obtaining end-user authorization, the end user may not understand the scope of the access being granted and to whom, or they may end up providing a client with access to resources that should not be permitted.
エンドユーザーの承認を取得するとき、エンドユーザーは許可されているアクセスの範囲と誰に許可されているかを理解していないか、許可されるべきでないリソースへのアクセスをクライアントに提供してしまう可能性があります。
Countermeasures:
対応策：
o Explain the scope (resources and the permissions) the user is about to grant in an understandable way (Section 5.2.4.2).
o ユーザーが理解しようとしている方法（セクション5.2.4.2）で付与しようとしているスコープ（リソースと権限）を説明します。
o Narrow the scope, based on the client. When obtaining end-user authorization and where the client requests scope, the authorization server may want to consider whether to honor that scope based on the client identifier. That decision is between the client and authorization server and is outside the scope of this spec. The authorization server may also want to consider what scope to grant based on the client type, e.g., providing lower scope to public clients (Section 5.1.5.1).
o クライアントに基づいて範囲を絞り込みます。エンドユーザーの承認を取得するときに、クライアントがスコープを要求する場合、承認サーバーは、クライアント識別子に基づいてそのスコープを尊重するかどうかを検討する必要があります。その決定はクライアントと許可サーバーの間で行われ、この仕様の範囲外です。承認サーバーは、クライアントのタイプに基づいて、どのスコープを付与するかを検討することもできます（例：パブリッククライアントに低いスコープを提供する（セクション5.1.5.1））。
Authorization servers may wish to automatically process authorization requests from clients that have been previously authorized by the user. When the user is redirected to the authorization server's end-user authorization endpoint to grant access, the authorization server detects that the user has already granted access to that particular client. Instead of prompting the user for approval, the authorization server automatically redirects the user back to the client.
承認サーバーは、ユーザーによって以前に承認されたクライアントからの承認リクエストを自動的に処理したい場合があります。ユーザーが認証サーバーのエンドユーザー認証エンドポイントにリダイレクトされてアクセスが許可されると、認証サーバーはユーザーがその特定のクライアントへのアクセスをすでに許可していることを検出します。承認サーバーは、ユーザーに承認を求める代わりに、ユーザーをクライアントに自動的にリダイレクトします。
A malicious client may exploit that feature and try to obtain such an authorization "code" instead of the legitimate client.
悪意のあるクライアントがその機能を悪用して、正当なクライアントの代わりにそのような認証「コード」を取得しようとする場合があります。
Countermeasures:
対応策：
o Authorization servers should not automatically process repeat authorizations to public clients unless the client is validated using a pre-registered redirect URI (Section 5.2.3.5).
o 事前に登録されたリダイレクトURI（セクション5.2.3.5）を使用してクライアントが検証されない限り、承認サーバーはパブリッククライアントに対する繰り返し承認を自動的に処理しないでください。
o Authorization servers can mitigate the risks associated with automatic processing by limiting the scope of access tokens obtained through automated approvals (Section 5.1.5.1).
o 承認サーバーは、自動承認を通じて取得されるアクセストークンの範囲を制限することで、自動処理に関連するリスクを軽減できます（セクション5.1.5.1）。
An attacker could use the end-user authorization endpoint and the redirect URI parameter to abuse the authorization server as an open redirector. An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation.
攻撃者は、エンドユーザーの認証エンドポイントとリダイレクトURIパラメータを使用して、認証サーバーをオープンリダイレクタとして悪用する可能性があります。オープンリダイレクターは、パラメーターを使用して、検証なしでパラメーター値で指定された場所にユーザーエージェントを自動的にリダイレクトするエンドポイントです。
Impact: An attacker could utilize a user's trust in an authorization server to launch a phishing attack.
影響：攻撃者は、認可サーバーに対するユーザーの信頼を利用して、フィッシング攻撃を仕掛ける可能性があります。
Countermeasures:
対応策：
o Require clients to register any full redirect URIs (Section 5.2.3.5).
o クライアントにすべてのリダイレクトURIを登録するように要求します（セクション5.2.3.5）。
o Don't redirect to a redirect URI if the client identifier or redirect URI can't be verified (Section 5.2.3.5).
o クライアント識別子またはリダイレクトURIを検証できない場合は、リダイレクトURIにリダイレクトしないでください（セクション5.2.3.5）。
Attackers may attempt to eavesdrop access tokens in transit from the authorization server to the client.
攻撃者は、認証サーバーからクライアントへの送信中にアクセストークンを盗聴しようとする可能性があります。
Impact: The attacker is able to access all resources with the permissions covered by the scope of the particular access token.
影響：攻撃者は、特定のアクセストークンのスコープでカバーされる権限を持つすべてのリソースにアクセスできます。
Countermeasures:
対応策：
o As per the core OAuth spec, the authorization servers must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1).
o コアOAuth仕様に従って、承認サーバーはこれらの送信がTLSなどのトランスポート層メカニズムを使用して保護されていることを確認する必要があります（セクション5.1.1を参照）。
o If end-to-end confidentiality cannot be guaranteed, reducing scope (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access tokens can be used to reduce the damage in case of leaks.
o エンドツーエンドの機密性を保証できない場合は、アクセストークンのスコープ（5.1.5.1を参照）と有効期限（5.1.5.3を参照）を減らすことで、リークが発生した場合の損傷を減らすことができます。
4.3.2. Threat: Obtaining Access Tokens from Authorization Server Database
4.3.2. 脅威：承認サーバーデータベースからのアクセストークンの取得
This threat is applicable if the authorization server stores access tokens as handles in a database. An attacker may obtain access tokens from the authorization server's database by gaining access to the database or launching a SQL injection attack.
この脅威は、認証サーバーがアクセストークンをハンドルとしてデータベースに保存している場合に発生します。攻撃者は、データベースへのアクセスを取得するか、SQLインジェクション攻撃を開始することにより、認証サーバーのデータベースからアクセストークンを取得する可能性があります。
Impact: Disclosure of all access tokens.
影響：すべてのアクセストークンの開示。
Countermeasures:
対応策：
o Enforce system security measures (Section 5.1.4.1.1).
o システムのセキュリティ対策を実施する（セクション5.1.4.1.1）。
o Store access token hashes only (Section 5.1.4.1.3).
o アクセストークンハッシュのみを保存します（セクション5.1.4.1.3）。
o Enforce standard SQL injection countermeasures (Section 5.1.4.1.2).
o 標準のSQLインジェクション対策を実施する（セクション5.1.4.1.2）。
An attacker could attempt to eavesdrop the transmission of client credentials between the client and server during the client authentication process or during OAuth token requests.
攻撃者は、クライアント認証プロセス中またはOAuthトークン要求中に、クライアントとサーバー間のクライアント資格情報の送信を盗聴する可能性があります。
Impact: Revelation of a client credential enabling phishing or impersonation of a client service.
影響：クライアントサービスのフィッシングまたは偽装を可能にするクライアント資格情報の暴露。
Countermeasures:
対応策：
o The transmission of client credentials must be protected using transport-layer mechanisms such as TLS (see Section 5.1.1).
o クライアント資格情報の送信は、TLSなどのトランスポート層メカニズムを使用して保護する必要があります（セクション5.1.1を参照）。
o Use alternative authentication means that do not require the sending of plaintext credentials over the wire (e.g., Hash-based Message Authentication Code).
o 代替認証を使用することは、平文の資格情報をネットワーク経由で送信する必要がないことを意味します（たとえば、ハッシュベースのメッセージ認証コード）。
4.3.4. Threat: Obtaining Client Secret from Authorization Server Database
4.3.4. 脅威：承認サーバーデータベースからのクライアントシークレットの取得
An attacker may obtain valid "client_id"/secret combinations from the authorization server's database by gaining access to the database or launching a SQL injection attack.
攻撃者は、データベースにアクセスするか、SQLインジェクション攻撃を開始することにより、認証サーバーのデータベースから有効な「client_id」/シークレットの組み合わせを取得する可能性があります。
Impact: Disclosure of all "client_id"/secret combinations. This allows the attacker to act on behalf of legitimate clients.
影響：すべての「client_id」/シークレットの組み合わせの開示。これにより、攻撃者は正当なクライアントに代わって行動することができます。
Countermeasures:
対応策：
o Enforce system security measures (Section 5.1.4.1.1).
o システムのセキュリティ対策を実施する（セクション5.1.4.1.1）。
o Enforce standard SQL injection countermeasures (Section 5.1.4.1.2).
o 標準のSQLインジェクション対策を実施する（セクション5.1.4.1.2）。
o Ensure proper handling of credentials as per "Enforce Credential Storage Protection Best Practices" (Section 5.1.4.1).
o 「資格情報ストレージ保護のベストプラクティスを実施する」（セクション5.1.4.1）に従って、資格情報の適切な処理を確認します。
An attacker may try to guess valid "client_id"/secret pairs.
攻撃者は有効な「client_id」/秘密のペアを推測しようとする可能性があります。
Impact: Disclosure of a single "client_id"/secret pair.
影響：単一の「client_id」/秘密のペアの開示。
Countermeasures:
対応策：
o Use high entropy for secrets (Section 5.1.4.2.2).
o 秘密には高いエントロピーを使用します（セクション5.1.4.2.2）。
o Lock accounts (Section 5.1.4.2.3).
o アカウントをロックします（セクション5.1.4.2.3）。
o Use strong client authentication (Section 5.2.3.7).
o 強力なクライアント認証を使用します（セクション5.2.3.7）。
This section covers threats that are specific to certain flows utilized to obtain access tokens. Each flow is characterized by response types and/or grant types on the end-user authorization and token endpoint, respectively.
このセクションでは、アクセストークンを取得するために利用される特定のフローに固有の脅威について説明します。各フローは、それぞれエンドユーザー認証とトークンエンドポイントの応答タイプまたは許可タイプ、あるいはその両方によって特徴付けられます。
An attacker could try to eavesdrop transmission of the authorization "code" between the authorization server and client. Furthermore, authorization "codes" are passed via the browser, which may unintentionally leak those codes to untrusted web sites and attackers in different ways:
攻撃者は、認証サーバーとクライアント間の認証「コード」の送信を盗聴する可能性があります。さらに、承認「コード」はブラウザを介して渡されるため、これらのコードが信頼できないWebサイトや攻撃者にさまざまな方法で意図せず漏洩する可能性があります。
o Referrer headers: Browsers frequently pass a "referer" header when a web page embeds content, or when a user travels from one web page to another web page. These referrer headers may be sent even when the origin site does not trust the destination site. The referrer header is commonly logged for traffic analysis purposes.
o リファラーヘッダー：ブラウザーは、Webページにコンテンツが埋め込まれているとき、またはユーザーがあるWebページから別のWebページに移動したときに、「リファラー」ヘッダーを頻繁に渡します。これらのリファラーヘッダーは、送信元サイトが送信先サイトを信頼していない場合でも送信される場合があります。リファラーヘッダーは、通常、トラフィック分析のためにログに記録されます。
o Request logs: Web server request logs commonly include query parameters on requests.
o リクエストログ：Webサーバーのリクエストログには通常、リクエストのクエリパラメータが含まれます。
o Open redirectors: Web sites sometimes need to send users to another destination via a redirector. Open redirectors pose a particular risk to web-based delegation protocols because the redirector can leak verification codes to untrusted destination sites.
o オープンリダイレクタ：Webサイトでは、リダイレクタを介してユーザーを別の宛先に送信する必要がある場合があります。オープンリダイレクタは、信頼できない宛先サイトに検証コードを漏らす可能性があるため、Webベースの委任プロトコルに特定のリスクをもたらします。
o Browser history: Web browsers commonly record visited URLs in the browser history. Another user of the same web browser may be able to view URLs that were visited by previous users.
o ブラウザーの履歴：Webブラウザーは通常、訪問したURLをブラウザーの履歴に記録します。同じWebブラウザーの別のユーザーが、以前のユーザーがアクセスしたURLを表示できる場合があります。
Note: A description of similar attacks on the SAML protocol can be found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1; [Sec-Analysis]; and [OASIS.sstc-sec-analysis-response-01].
注：SAMLプロトコルに対する同様の攻撃の説明は、[OASIS.sstc-saml-bindings-1.1]、セクション4.1.1.9.1にあります。 [Sec-Analysis];および[OASIS.sstc-sec-analysis-response-01]。
Countermeasures:
対応策：
o As per the core OAuth spec, the authorization server as well as the client must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1).
o コアOAuth仕様に従って、認証サーバーとクライアントは、TLSなどのトランスポート層メカニズムを使用してこれらの送信が確実に保護されるようにする必要があります（セクション5.1.1を参照）。
o The authorization server will require the client to authenticate wherever possible, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).
o 認可サーバーは、可能な限りクライアントを認証するように要求するため、特定のクライアントへの認可「コード」のバインディングは、信頼できる方法で検証できます（セクション5.2.4.4を参照）。
o Use short expiry time for authorization "codes" (Section 5.1.5.3).
o 承認「コード」には短い有効期限を使用します（セクション5.1.5.3）。
o The authorization server should enforce a one-time usage restriction (see Section 5.1.5.4).
o 認可サーバーは、1回限りの使用制限を適用する必要があります（セクション5.1.5.4を参照）。
o If an authorization server observes multiple attempts to redeem an authorization "code", the authorization server may want to revoke all tokens granted based on the authorization "code" (see Section 5.2.1.1).
o 承認サーバーが承認「コード」を引き換えようとする複数の試みを観察する場合、承認サーバーは承認「コード」に基づいて付与されたすべてのトークンを取り消す場合があります（セクション5.2.1.1を参照）。
o In the absence of these countermeasures, reducing scope (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access tokens can be used to reduce the damage in case of leaks.
o これらの対策がない場合、アクセストークンのスコープ（5.1.5.1節）と有効期限（5.1.5.3節）を減らすことで、リークが発生した場合の損傷を減らすことができます。
o The client server may reload the target page of the redirect URI in order to automatically clean up the browser cache.
o クライアントサーバーは、ブラウザキャッシュを自動的にクリーンアップするために、リダイレクトURIのターゲットページをリロードする場合があります。
4.4.1.2. Threat: Obtaining Authorization "codes" from Authorization Server Database
4.4.1.2. 脅威：承認サーバーデータベースから承認「コード」を取得する
This threat is applicable if the authorization server stores authorization "codes" as handles in a database. An attacker may obtain authorization "codes" from the authorization server's database by gaining access to the database or launching a SQL injection attack.
この脅威は、認証サーバーが認証の「コード」をデータベースのハンドルとして保存している場合に発生します。攻撃者は、データベースへのアクセスを取得するか、SQLインジェクション攻撃を開始することにより、認証サーバーのデータベースから認証「コード」を取得する可能性があります。
Impact: Disclosure of all authorization "codes", most likely along with the respective "redirect_uri" and "client_id" values.
影響：ほとんどの場合、それぞれの「redirect_uri」および「client_id」の値とともに、すべての認証「コード」の開示。
Countermeasures:
対応策：
o Best practices for credential storage protection should be employed (Section 5.1.4.1).
o 資格情報ストレージ保護のベストプラクティスを採用する必要があります（セクション5.1.4.1）。
o Enforce system security measures (Section 5.1.4.1.1).
o システムのセキュリティ対策を実施する（セクション5.1.4.1.1）。
o Store access token hashes only (Section 5.1.4.1.3).
o アクセストークンハッシュのみを保存します（セクション5.1.4.1.3）。
o Enforce standard SQL injection countermeasures (Section 5.1.4.1.2).
o 標準のSQLインジェクション対策を実施する（セクション5.1.4.1.2）。
An attacker may try to guess valid authorization "code" values and send the guessed code value using the grant type "code" in order to obtain a valid access token.
攻撃者は有効な認証「コード」値を推測し、許可されたタイプ「コード」を使用して推測されたコード値を送信して、有効なアクセストークンを取得する可能性があります。
Impact: Disclosure of a single access token and probably also an associated refresh token.
影響：単一のアクセストークン、およびおそらく関連する更新トークンの開示。
Countermeasures:
対応策：
o Handle-based tokens must use high entropy (Section 5.1.4.2.2).
o ハンドルベースのトークンは、高エントロピーを使用する必要があります（セクション5.1.4.2.2）。
o Assertion-based tokens should be signed (Section 5.1.5.9).
o アサーションベースのトークンに署名する必要があります（セクション5.1.5.9）。
o Authenticate the client; this adds another value that the attacker has to guess (Section 5.2.3.4).
o クライアントを認証します。これにより、攻撃者が推測しなければならない別の値が追加されます（セクション5.2.3.4）。
o Bind the authorization "code" to the redirect URI; this adds another value that the attacker has to guess (Section 5.2.4.5).
o 承認「コード」をリダイレクトURIにバインドします。これにより、攻撃者が推測しなければならない別の値が追加されます（セクション5.2.4.5）。
o Use short expiry time for tokens (Section 5.1.5.3).
o トークンには短い有効期限を使用します（セクション5.1.5.3）。
A malicious client could pretend to be a valid client and obtain an access authorization in this way. The malicious client could even utilize screen-scraping techniques in order to simulate a user's consent in the authorization flow.
悪意のあるクライアントが有効なクライアントのふりをして、この方法でアクセス許可を取得する可能性があります。悪意のあるクライアントは、認証フローでのユーザーの同意をシミュレートするために、画面スクレイピング技術を利用することさえできます。
Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device, probably in cooperation with other components of the respective ecosystem (e.g., an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources maintained in resource servers and to prevent unauthorized access to them via the OAuth protocol. Based on this assumption, the following countermeasures are available to cope with the threat.
前提：エンドユーザーのデバイスを悪意のあるソフトウェアから保護することは、承認サーバーの役割ではありません。これは、おそらくそれぞれのエコシステムの他のコンポーネント（アプリケーション管理インフラストラクチャなど）と連携して、特定のデバイスで実行されるプラットフォームの責任です。承認サーバーの唯一の責任は、リソースサーバーに保持されているエンドユーザーのリソースへのアクセスを制御し、OAuthプロトコルを介してエンドユーザーへの不正アクセスを防止することです。この想定に基づいて、脅威に対処するために以下の対策を利用できます。
Countermeasures:
対応策：
o The authorization server should authenticate the client, if possible (see Section 5.2.3.4). Note: The authentication takes place after the end user has authorized the access.
o 許可サーバーは、可能であればクライアントを認証する必要があります（セクション5.2.3.4を参照）。注：認証は、エンドユーザーがアクセスを承認した後に行われます。
o The authorization server should validate the client's redirect URI against the pre-registered redirect URI, if one exists (see Section 5.2.3.5). Note: An invalid redirect URI indicates an invalid client, whereas a valid redirect URI does not necessarily indicate a valid client. The level of confidence depends on the client type. For web applications, the level of confidence is high, since the redirect URI refers to the globally unique network endpoint of this application, whose fully qualified domain name (FQDN) is also validated using HTTPS server authentication by the user agent. In contrast, for native clients, the redirect URI typically refers to device local resources, e.g., a custom scheme. So, a malicious client on a particular device can use the valid redirect URI the legitimate client uses on all other devices.
o 認可サーバーは、事前に登録されたリダイレクトURIが存在する場合、クライアントのリダイレクトURIを検証する必要があります（セクション5.2.3.5を参照）。注：無効なリダイレクトURIは無効なクライアントを示しますが、有効なリダイレクトURIは必ずしも有効なクライアントを示すわけではありません。信頼度はクライアントのタイプによって異なります。 Webアプリケーションの場合、リダイレクトURIはこのアプリケーションのグローバルに一意のネットワークエンドポイントを参照するため、信頼度は高くなります。その完全修飾ドメイン名（FQDN）も、ユーザーエージェントによるHTTPSサーバー認証を使用して検証されます。対照的に、ネイティブクライアントの場合、リダイレクトURIは通常、カスタムスキームなどのデバイスローカルリソースを指します。したがって、特定のデバイス上の悪意のあるクライアントは、正当なクライアントが他のすべてのデバイスで使用する有効なリダイレクトURIを使用できます。
o After authenticating the end user, the authorization server should ask him/her for consent. In this context, the authorization server should explain to the end user the purpose, scope, and duration of the authorization the client asked for. Moreover, the authorization server should show the user any identity information it has for that client. It is up to the user to validate the binding of this data to the particular application (e.g., Name) and to approve the authorization request (see Section 5.2.4.3).
o エンドユーザーを認証した後、承認サーバーはエンドユーザーに同意を求める必要があります。このコンテキストでは、承認サーバーは、クライアントが要求した承認の目的、範囲、および期間をエンドユーザーに説明する必要があります。さらに、認可サーバーは、ユーザーがそのクライアントに対して持っているID情報をユーザーに表示する必要があります。このデータと特定のアプリケーション（例：名前）のバインドを検証し、承認リクエストを承認するかどうかは、ユーザー次第です（セクション5.2.4.3を参照）。
o The authorization server should not perform automatic re-authorizations for clients it is unable to reliably authenticate or validate (see Section 5.2.4.1).
o 認可サーバーは、確実に認証または検証できないクライアントに対して自動再認可を実行するべきではありません（セクション5.2.4.1を参照）。
o If the authorization server automatically authenticates the end user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs (Completely Automated Public Turing tests to tell Computers and Humans Apart) or other multi-factor authentication techniques such as random questions, token code generators, etc.
o 承認サーバーがエンドユーザーを自動的に認証する場合でも、画面のスクレイピングを防ぐためにユーザー入力が必要になる場合があります。例としては、CAPTCHA（コンピューターと人間を区別するための完全に自動化されたパブリックチューリングテスト）や、ランダムな質問、トークンコードジェネレーターなどの他の多要素認証技術があります。
o The authorization server may also limit the scope of tokens it issues to clients it cannot reliably authenticate (see Section 5.1.5.1).
o 認可サーバーは、信頼できる認証ができないクライアントに発行するトークンの範囲を制限する場合もあります（セクション5.1.5.1を参照）。
A hostile party could impersonate the client site and get access to the authorization "code". This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user's browser is running.
敵対的な当事者がクライアントサイトになりすまして、認証「コード」にアクセスする可能性があります。これは、DNSまたはARPスプーフィングを使用して実現できます。これは、Webアプリケーションであるクライアントに適用されます。したがって、リダイレクトURIは、ユーザーのブラウザーが実行されているホストに対してローカルではありません。
Impact: This affects web applications and may lead to a disclosure of authorization "codes" and, potentially, the corresponding access and refresh tokens.
影響：これはWebアプリケーションに影響を与え、承認「コード」の開示につながり、場合によっては対応するアクセストークンと更新トークンが開示される可能性があります。
Countermeasures:
対応策：
It is strongly recommended that one of the following countermeasures be utilized in order to prevent this attack:
この攻撃を防ぐために、次のいずれかの対策を講じることを強くお勧めします。
o The redirect URI of the client should point to an HTTPS-protected endpoint, and the browser should be utilized to authenticate this redirect URI using server authentication (see Section 5.1.2).
o クライアントのリダイレクトURIはHTTPSで保護されたエンドポイントを指す必要があり、サーバー認証を使用してこのリダイレクトURIを認証するためにブラウザーを利用する必要があります（セクション5.1.2を参照）。
o The authorization server should require that the client be authenticated, i.e., confidential client, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).
o 認可サーバーは、クライアントが認証されていること、つまり機密クライアントを要求する必要があります。これにより、特定のクライアントへの認可「コード」のバインディングを信頼できる方法で検証できます（セクション5.2.4.4を参照）。
A hostile party could impersonate the client site and impersonate the user's session on this client. This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user's browser is running.
敵対者は、クライアントサイトを偽装し、このクライアントでのユーザーのセッションを偽装する可能性があります。これは、DNSまたはARPスプーフィングを使用して実現できます。これは、Webアプリケーションであるクライアントに適用されます。したがって、リダイレクトURIは、ユーザーのブラウザーが実行されているホストに対してローカルではありません。
Impact: An attacker who intercepts the authorization "code" as it is sent by the browser to the callback endpoint can gain access to protected resources by submitting the authorization "code" to the client. The client will exchange the authorization "code" for an access token and use the access token to access protected resources for the benefit of the attacker, delivering protected resources to the attacker, or modifying protected resources as directed by the attacker. If OAuth is used by the client to delegate authentication to a social site (e.g., as in the implementation of a "Login" button on a third-party social network site), the attacker can use the intercepted authorization "code" to log into the client as the user.
影響：ブラウザからコールバックエンドポイントに送信される認証「コード」を傍受する攻撃者は、認証「コード」をクライアントに送信することにより、保護されたリソースにアクセスできます。クライアントは認証「コード」をアクセストークンに交換し、アクセストークンを使用して保護されたリソースにアクセスし、攻撃者のために保護されたリソースを攻撃者に配信するか、攻撃者の指示に従って保護されたリソースを変更します。クライアントがOAuthを使用して認証をソーシャルサイトに委任した場合（サードパーティのソーシャルネットワークサイトの[ログイン]ボタンの実装など）、攻撃者は傍受した認証「コード」を使用してログインできます。ユーザーとしてのクライアント。
Note: Authenticating the client during authorization "code" exchange will not help to detect such an attack, as it is the legitimate client that obtains the tokens.
注：認可「コード」交換中にクライアントを認証しても、トークンを取得するのは正当なクライアントであるため、このような攻撃の検出には役立ちません。
Countermeasures:
対応策：
o In order to prevent an attacker from impersonating the end-user's session, the redirect URI of the client should point to an HTTPS protected endpoint, and the browser should be utilized to authenticate this redirect URI using server authentication (see Section 5.1.2).
o 攻撃者がエンドユーザーのセッションを偽装するのを防ぐために、クライアントのリダイレクトURIはHTTPSで保護されたエンドポイントを指し、ブラウザはサーバー認証を使用してこのリダイレクトURIを認証する必要があります（セクション5.1.2を参照）。
4.4.1.7. Threat: Authorization "code" Leakage through Counterfeit Client
4.4.1.7. 脅威：偽造クライアントによる認証「コード」の漏洩
The attacker leverages the authorization "code" grant type in an attempt to get another user (victim) to log in, authorize access to his/her resources, and subsequently obtain the authorization "code" and inject it into a client application using the attacker's account. The goal is to associate an access authorization for resources of the victim with the user account of the attacker on a client site.
攻撃者は、承認「コード」付与タイプを利用して、別のユーザー（被害者）にログインを許可し、自分のリソースへのアクセスを承認し、その後、承認「コード」を取得し、攻撃者のコードを使用してクライアントアプリケーションに挿入しますアカウント。目標は、被害者のリソースに対するアクセス許可を、クライアントサイトの攻撃者のユーザーアカウントに関連付けることです。
The attacker abuses an existing client application and combines it with his own counterfeit client web site. The attacker depends on the victim expecting the client application to request access to a certain resource server. The victim, seeing only a normal request from an expected application, approves the request. The attacker then uses the victim's authorization to gain access to the information unknowingly authorized by the victim.
攻撃者は既存のクライアントアプリケーションを悪用し、それを自分の偽造クライアントWebサイトと組み合わせます。攻撃者は、クライアントアプリケーションが特定のリソースサーバーへのアクセスを要求することを期待している被害者に依存します。被害者は、予期されたアプリケーションからの通常のリクエストのみを見て、リクエストを承認します。次に、攻撃者は被害者の承認を使用して、知らないうちに被害者によって承認された情報にアクセスします。
The attacker conducts the following flow:
攻撃者は次のフローを実行します。
1. The attacker accesses the client web site (or application) and initiates data access to a particular resource server. The client web site in turn initiates an authorization request to the resource server's authorization server. Instead of proceeding with the authorization process, the attacker modifies the authorization server end-user authorization URL as constructed by the client to include a redirect URI parameter referring to a web site under his control (attacker's web site).
1. 攻撃者はクライアントのWebサイト（またはアプリケーション）にアクセスし、特定のリソースサーバーへのデータアクセスを開始します。クライアントのWebサイトは、リソースサーバーの承認サーバーへの承認要求を開始します。攻撃者は、承認プロセスを続行する代わりに、クライアントが作成した承認サーバーのエンドユーザー承認URLを変更して、自分の制御下にあるWebサイト（攻撃者のWebサイト）を参照するリダイレクトURIパラメーターを含めます。
2. The attacker tricks another user (the victim) into opening that modified end-user authorization URI and authorizing access (e.g., via an email link or blog link). The way the attacker achieves this goal is out of scope.
2. 攻撃者は別のユーザー（被害者）をだまして、変更されたエンドユーザー認証URIを開き、アクセスを許可します（たとえば、電子メールリンクやブログリンクを介して）。攻撃者がこの目標を達成する方法は範囲外です。
3. Having clicked the link, the victim is requested to authenticate and authorize the client site to have access.
3. リンクをクリックすると、被害者はクライアントサイトへのアクセスを認証および承認するように要求されます。
4. After completion of the authorization process, the authorization server redirects the user agent to the attacker's web site instead of the original client web site.
4. 承認プロセスが完了すると、承認サーバーはユーザーエージェントを元のクライアントWebサイトではなく、攻撃者のWebサイトにリダイレクトします。
5. The attacker obtains the authorization "code" from his web site by means that are out of scope of this document.
5. 攻撃者は、このドキュメントの範囲外の方法でWebサイトから認証「コード」を取得します。
6. He then constructs a redirect URI to the target web site (or application) based on the original authorization request's redirect URI and the newly obtained authorization "code", and directs his user agent to this URL. The authorization "code" is injected into the original client site (or application).
6. 次に、元の承認リクエストのリダイレクトURIと新しく取得した承認「コード」に基づいて、ターゲットWebサイト（またはアプリケーション）へのリダイレクトURIを作成し、ユーザーエージェントをこのURLに転送します。承認「コード」は、元のクライアントサイト（またはアプリケーション）に挿入されます。
7. The client site uses the authorization "code" to fetch a token from the authorization server and associates this token with the attacker's user account on this site.
7. クライアントサイトは認証「コード」を使用して認証サーバーからトークンをフェッチし、このトークンをこのサイトの攻撃者のユーザーアカウントに関連付けます。
8. The attacker may now access the victim's resources using the client site.
8. 攻撃者は、クライアントサイトを使用して被害者のリソースにアクセスできるようになります。
Impact: The attacker gains access to the victim's resources as associated with his account on the client site.
影響：攻撃者は、クライアントサイトのアカウントに関連付けられている被害者のリソースにアクセスできます。
Countermeasures:
対応策：
o The attacker will need to use another redirect URI for its authorization process rather than the target web site because it needs to intercept the flow. So, if the authorization server associates the authorization "code" with the redirect URI of a particular end-user authorization and validates this redirect URI with the redirect URI passed to the token's endpoint, such an attack is detected (see Section 5.2.4.5).
o 攻撃者はフローを傍受する必要があるため、ターゲットWebサイトではなく、認証プロセスに別のリダイレクトURIを使用する必要があります。したがって、承認サーバーが承認「コード」を特定のエンドユーザー承認のリダイレクトURIに関連付け、このリダイレクトURIをトークンのエンドポイントに渡されたリダイレクトURIで検証すると、このような攻撃が検出されます（セクション5.2.4.5を参照） 。
o The authorization server may also enforce the usage and validation of pre-registered redirect URIs (see Section 5.2.3.5). This will allow for early recognition of authorization "code" disclosure to counterfeit clients.
o 承認サーバーは、事前に登録されたリダイレクトURIの使用と検証を実施する場合もあります（セクション5.2.3.5を参照）。これにより、偽造クライアントへの承認「コード」開示の早期認識が可能になります。
o For native applications, one could also consider using deployment-specific client ids and secrets (see Section 5.2.3.4), along with the binding of authorization "codes" to "client_ids" (see Section 5.2.4.4) to detect such an attack because the attacker does not have access to the deployment-specific secret. Thus, he will not be able to exchange the authorization "code".
o ネイティブアプリケーションの場合、デプロイメント固有のクライアントIDとシークレット（セクション5.2.3.4を参照）を使用して、認証 "コード"を "client_ids"（セクション5.2.4.4を参照）にバインドして、このような攻撃を検出することも検討できます。攻撃者はデプロイメント固有のシークレットにアクセスできません。したがって、彼は許可「コード」を交換することができません。
o The client may consider using other flows that are not vulnerable to this kind of attack, such as the implicit grant type (see Section 4.4.2) or resource owner password credentials (see Section 4.4.3).
o クライアントは、暗黙の付与タイプ（セクション4.4.2を参照）やリソース所有者のパスワード資格情報（セクション4.4.3を参照）など、この種の攻撃に対して脆弱ではない他のフローの使用を検討する場合があります。
Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the web site trusts or has authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the user.
クロスサイトリクエストフォージェリ（CSRF）は、Webベースの攻撃で、Webサイトが信頼するか、または認証したユーザーからHTTPリクエストが送信されます（HTTPリダイレクトやHTMLフォームなどを介して）。 OAuth承認に対するCSRF攻撃により、攻撃者はユーザーの同意なしにOAuthで保護されたリソースへの承認を取得できます。
This attack works against the redirect URI used in the authorization "code" flow. An attacker could authorize an authorization "code" to their own protected resources on an authorization server. He then aborts the redirect flow back to the client on his device and tricks the victim into executing the redirect back to the client. The client receives the redirect, fetches the token(s) from the authorization server, and associates the victim's client session with the resources accessible using the token.
この攻撃は、認証「コード」フローで使用されるリダイレクトURIに対して機能します。攻撃者は、承認サーバー上の保護された独自のリソースに対する承認「コード」を承認する可能性があります。次に、デバイス上のクライアントへのリダイレクトフローを中止し、被害者をだましてクライアントへのリダイレクトを実行させます。クライアントはリダイレクトを受信し、認証サーバーからトークンをフェッチして、被害者のクライアントセッションを、トークンを使用してアクセス可能なリソースに関連付けます。
Impact: The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker's resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker's identity at the external Identity Provider. In this way, the attacker could easily access the victim's data at the client by logging in from another device with his credentials at the external Identity Provider.
影響：ユーザーは攻撃者に代わってリソースにアクセスします。効果的な影響は、アクセスされるリソースのタイプによって異なります。たとえば、ユーザーがプライベートアイテムを攻撃者のリソースにアップロードする可能性があります。または、サードパーティのログインシナリオでOAuthを使用する場合、ユーザーは自分のクライアントアカウントを外部IDプロバイダーの攻撃者のIDに関連付けることができます。このようにして、攻撃者は外部のアイデンティティプロバイダーに自分の資格情報を使用して別のデバイスからログインすることにより、クライアントで被害者のデータに簡単にアクセスできます。
Countermeasures:
対応策：
o The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token (Section 5.3.5).
o 「state」パラメータを使用して、認証リクエストをアクセストークンの配信に使用されるリダイレクトURIにリンクする必要があります（セクション5.3.5）。
o Client developers and end users can be educated to not follow untrusted URLs.
o クライアント開発者とエンドユーザーは、信頼できないURLをたどらないように教育することができます。
With clickjacking, a malicious site loads the target site in a transparent iFrame (see [iFrame]) overlaid on top of a set of dummy buttons that are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an "Authorize" button) on the hidden page.
悪意のあるサイトはクリックジャッキングを使用して、ターゲットサイトの重要なボタンの真下に配置されるように注意深く作成されたダミーボタンのセットの上にオーバーレイされた透明なiFrame（[iFrame]を参照）にターゲットサイトを読み込みます。ユーザーが表示されているボタンをクリックすると、実際には非表示ページのボタン（「承認」ボタンなど）がクリックされます。
Impact: An attacker can steal a user's authentication credentials and access their resources.
影響：攻撃者は、ユーザーの認証資格情報を盗み、そのリソースにアクセスする可能性があります。
Countermeasures:
対応策：
o For newer browsers, avoidance of iFrames during authorization can be enforced on the server side by using the X-FRAME-OPTIONS header (Section 5.2.2.6).
o 新しいブラウザーの場合、X-FRAME-OPTIONSヘッダーを使用することで、認証中のiFrameの回避をサーバー側で強制できます（セクション5.2.2.6）。
o For older browsers, JavaScript frame-busting (see [Framebusting]) techniques can be used but may not be effective in all browsers.
o 古いブラウザでは、JavaScriptフレームバスティング（[フレームバスティング]を参照）の手法を使用できますが、すべてのブラウザで効果があるとは限りません。
When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically and simulating the flow against the authorization server. That way, the client may gain access to the victim's resources without her approval. An authorization server will be vulnerable to this threat if it uses non-interactive authentication mechanisms or splits the authorization flow across multiple pages.
クライアントが保護されたリソースへのアクセスを要求する場合、認証フローには通常、保護されたリソースへのアクセスを許可または拒否する、アクセス要求に対するリソース所有者の明示的な応答が含まれます。悪意のあるクライアントは、必要なリクエストをプログラムで送信し、承認サーバーに対してフローをシミュレートすることにより、リソース所有者の同意なしに承認を得るために、このフローの構造の知識を利用できます。このようにして、クライアントは被害者の承認なしに被害者のリソースにアクセスできます。承認サーバーが非対話型認証メカニズムを使用する場合、または承認フローを複数のページに分割する場合、承認サーバーはこの脅威に対して脆弱になります。
The malicious client might embed a hidden HTML user agent, interpret the HTML forms sent by the authorization server, and automatically send the corresponding form HTTP POST requests. As a prerequisite, the attacker must be able to execute the authorization process in the context of an already-authenticated session of the resource owner with the authorization server. There are different ways to achieve this:
悪意のあるクライアントが非表示のHTMLユーザーエージェントを埋め込み、認証サーバーから送信されたHTMLフォームを解釈し、対応するフォームのHTTP POSTリクエストを自動的に送信する可能性があります。前提条件として、攻撃者は、承認サーバーとのリソース所有者の既に認証されたセッションのコンテキストで承認プロセスを実行できる必要があります。これを実現する方法はいくつかあります。
o The malicious client could abuse an existing session in an external browser or cross-browser cookies on the particular device.
o 悪意のあるクライアントは、外部ブラウザーの既存のセッションまたは特定のデバイスのクロスブラウザーCookieを悪用する可能性があります。
o The malicious client could also request authorization for an initial scope acceptable to the user and then silently abuse the resulting session in his browser instance to "silently" request another scope.
o 悪意のあるクライアントは、ユーザーに受け入れられる最初のスコープの承認を要求し、ブラウザインスタンスの結果のセッションを黙って悪用して、別のスコープを「サイレント」に要求することもできます。
o Alternatively, the attacker might exploit an authorization server's ability to authenticate the resource owner automatically and without user interactions, e.g., based on certificates.
o または、攻撃者は、承認サーバーの機能を悪用して、リソースの所有者を自動的に認証します。たとえば、証明書に基づいて、ユーザーとの対話は必要ありません。
In all cases, such an attack is limited to clients running on the victim's device, either within the user agent or as a native app.
すべての場合において、このような攻撃は、ユーザーエージェント内またはネイティブアプリとして、被害者のデバイス上で実行されているクライアントに限定されます。
Please note: Such attacks cannot be prevented using CSRF countermeasures, since the attacker just "executes" the URLs as prepared by the authorization server including any nonce, etc.
注意：このような攻撃は、CSRF対策を使用して防止することはできません。攻撃者は、ナンスなどを含め、承認サーバーによって準備されたURLを単に「実行」するだけだからです。
Countermeasures:
対応策：
Authorization servers should decide, based on an analysis of the risk associated with this threat, whether to detect and prevent this threat.
承認サーバーは、この脅威に関連するリスクの分析に基づいて、この脅威を検出して防止するかどうかを決定する必要があります。
In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could
このような攻撃を防ぐために、承認サーバーは、ユーザー同意の承認の一部として、予測できない入力値に基づいてユーザーの操作を強制する場合があります。認可サーバーは
o combine password authentication and user consent in a single form,
o パスワード認証とユーザーの同意を単一の形式で組み合わせる
o make use of CAPTCHAs, or
o CAPTCHAを利用する、または
o use one-time secrets sent out of band to the resource owner (e.g., via text or instant message).
o 帯域外でリソース所有者に送信された1回限りのシークレットを使用します（テキストやインスタントメッセージなどを使用）。
Alternatively, in order to allow the resource owner to detect abuse, the authorization server could notify the resource owner of any approval by appropriate means, e.g., text or instant message, or email.
あるいは、リソース所有者が悪用を検出できるようにするために、承認サーバーは、テキストまたはインスタントメッセージ、または電子メールなどの適切な手段によって、リソース所有者に承認を通知することができます。
If an authorization server includes a nontrivial amount of entropy in authorization "codes" or access tokens (limiting the number of possible codes/tokens) and automatically grants either without user intervention and has no limit on codes or access tokens per user, an attacker could exhaust the pool of authorization "codes" by repeatedly directing the user's browser to request authorization "codes" or access tokens.
承認サーバーが承認の「コード」またはアクセストークンに重要なエントロピーを含み（可能なコード/トークンの数を制限）、ユーザーの介入なしに自動的に付与し、ユーザーごとのコードまたはアクセストークンに制限がない場合、攻撃者は承認「コード」またはアクセストークンを要求するようにユーザーのブラウザーに繰り返し指示することにより、承認「コード」のプールを使い果たします。
Countermeasures:
対応策：
o The authorization server should consider limiting the number of access tokens granted per user.
o 許可サーバーは、ユーザーごとに付与されるアクセストークンの数を制限することを検討する必要があります。
o The authorization server should include a nontrivial amount of entropy in authorization "codes".
o 認可サーバーは、認可「コード」に重要なエントロピーを含める必要があります。
An attacker who owns a botnet can locate the redirect URIs of clients that listen on HTTP, access them with random authorization "codes", and cause a large number of HTTPS connections to be concentrated onto the authorization server. This can result in a denial-of-service (DoS) attack on the authorization server.
ボットネットを所有する攻撃者は、HTTPでリッスンするクライアントのリダイレクトURIを見つけ、ランダムな認証「コード」でそれらにアクセスし、多数のHTTPS接続を認証サーバーに集中させることができます。これにより、認証サーバーでサービス拒否（DoS）攻撃が発生する可能性があります。
This attack can still be effective even when CSRF defense/the "state" parameter (see Section 4.4.1.8) is deployed on the client side. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/"state" parameter. This apparently cuts down the effectiveness of the attack by a factor of 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at [SSL-Latency]), the attacker still achieves a magnification of resource utilization at the expense of the authorization server.
この攻撃は、CSRF防御/「状態」パラメータ（セクション4.4.1.8を参照）がクライアント側にデプロイされている場合でも効果的です。このような防御の場合、攻撃者は有効なCSRFコード/「状態」パラメーターを取得するために追加のHTTPリクエストを要求する必要がある場合があります。これにより、攻撃の有効性は明らかに2倍に減少します。ただし、HTTPS / HTTPコスト比が2より大きい場合（[SSLレイテンシ]でのコスト係数は約3.5倍と推定されます）、攻撃者は依然として認可サーバーを犠牲にして、リソース使用率の拡大を実現します。
Impact: There are a few effects that the attacker can accomplish with this OAuth flow that they cannot easily achieve otherwise.
影響：攻撃者がこのOAuthフローを使用して達成できる影響はいくつかありますが、そうでなければ簡単に達成することはできません。
1. Connection laundering: With the clients as the relay between the attacker and the authorization server, the authorization server learns little or no information about the identity of the attacker. Defenses such as rate-limiting on the offending attacker machines are less effective because it is difficult to identify the attacking machines. Although an attacker could also launder its connections through an anonymizing system such as Tor, the effectiveness of that approach depends on the capacity of the anonymizing system. On the other hand, a potentially large number of OAuth clients could be utilized for this attack.
1. 接続ロンダリング：攻撃者と承認サーバーの間の中継としてクライアントを使用すると、承認サーバーは攻撃者のIDに関する情報をほとんどまたはまったく学習しません。攻撃している攻撃者のマシンをレート制限するなどの防御は、攻撃しているマシンを特定することが難しいため、効果が低くなります。攻撃者は、Torなどの匿名化システムを介して接続を洗浄することもできますが、そのアプローチの有効性は、匿名化システムの能力に依存します。一方、この攻撃では、潜在的に多数のOAuthクライアントが利用される可能性があります。
2. Asymmetric resource utilization: The attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the authorization server; the attacker can coordinate the timing of such HTTPS connections across multiple clients relatively easily. Although the attacker could achieve something similar, say, by including an iFrame pointing to the HTTPS URL of the authorization server in an HTTP web page and luring web users to visit that page, timing attacks using such a scheme may be more difficult, as it seems nontrivial to synchronize a large number of users to simultaneously visit a particular site under the attacker's control.
2.非対称的なリソース使用率：攻撃者はHTTP接続のコストを負担し、認証サーバーでHTTPS接続を確立させます。攻撃者は、このようなHTTPS接続のタイミングを複数のクライアント間で比較的簡単に調整できます。攻撃者は同様のことを行う可能性があります。たとえば、HTTP Webページに認証サーバーのHTTPS URLを指すiFrameを含め、Webユーザーがそのページにアクセスするよう誘導することにより、そのようなスキームを使用したタイミング攻撃はより困難になる可能性があります。多数のユーザーを同期させて、攻撃者の制御下にある特定のサイトに同時にアクセスすることは簡単ではないようです。
Countermeasures:
対応策：
o Though not a complete countermeasure by themselves, CSRF defense and the "state" parameter created with secure random codes should be deployed on the client side. The client should forward the authorization "code" to the authorization server only after both the CSRF token and the "state" parameter are validated.
o 完全な対策ではありませんが、CSRF防御と安全なランダムコードで作成された「状態」パラメータをクライアント側にデプロイする必要があります。クライアントは、CSRFトークンと「状態」パラメーターの両方が検証された後にのみ、認証「コード」を認証サーバーに転送する必要があります。
o If the client authenticates the user, either through a single-sign-on protocol or through local authentication, the client should suspend the access by a user account if the number of invalid authorization "codes" submitted by this user exceeds a certain threshold.
o クライアントがシングルサインオンプロトコルまたはローカル認証を使用してユーザーを認証する場合、このユーザーが送信した無効な認証「コード」の数が特定のしきい値を超えると、クライアントはユーザーアカウントによるアクセスを一時停止する必要があります。
o The authorization server should send an error response to the client reporting an invalid authorization "code" and rate-limit or disallow connections from clients whose number of invalid requests exceeds a threshold.
o 許可サーバーは、クライアントにエラー応答を送信して無効な許可「コード」を報告し、無効な要求の数がしきい値を超えるクライアントからの接続をレート制限または拒否する必要があります。
An attacker could attempt to log into an application or web site using a victim's identity. Applications relying on identity data provided by an OAuth protected service API to login users are vulnerable to this threat. This pattern can be found in so-called "social login" scenarios.
攻撃者は、被害者のIDを使用してアプリケーションまたはWebサイトへのログインを試みる可能性があります。 OAuthで保護されたサービスAPIがユーザーにログインするために提供するIDデータに依存するアプリケーションは、この脅威に対して脆弱です。このパターンは、いわゆる「ソーシャルログイン」シナリオで見られます。
As a prerequisite, a resource server offers an API to obtain personal information about a user that could be interpreted as having obtained a user identity. In this sense, the client is treating the resource server API as an "identity" API. A client utilizes OAuth to obtain an access token for the identity API. It then queries the identity API for an identifier and uses it to look up its internal user account data (login). The client assumes that, because it was able to obtain information about the user, the user has been authenticated.
前提条件として、リソースサーバーは、ユーザーIDを取得したと解釈できるユーザーに関する個人情報を取得するAPIを提供します。この意味で、クライアントはリソースサーバーAPIを「ID」APIとして扱います。クライアントはOAuthを使用してID APIのアクセストークンを取得します。次に、ID APIに識別子を照会し、それを使用して内部ユーザーアカウントデータを検索します（ログイン）。クライアントは、ユーザーに関する情報を取得できたため、ユーザーが認証されたと想定しています。
If the client uses the grant type "code", the attacker needs to gather a valid authorization "code" of the respective victim from the same Identity Provider used by the target client application. The attacker tricks the victim into logging into a malicious app (which may appear to be legitimate to the Identity Provider) using the same Identity Provider as the target application. This results in the Identity Provider's authorization server issuing an authorization
クライアントが許可タイプ「コード」を使用する場合、攻撃者は、ターゲットクライアントアプリケーションで使用されているものと同じアイデンティティプロバイダーから、それぞれの被害者の有効な認証「コード」を収集する必要があります。攻撃者は、ターゲットアプリケーションと同じIDプロバイダーを使用して、被害者をだまして悪意のあるアプリ（IDプロバイダーに正当なように見える可能性がある）にログインさせます。これにより、IDプロバイダーの承認サーバーが承認を発行します。
"code" for the respective identity API. The malicious app then sends this code to the attacker, which in turn triggers a login process within the target application. The attacker now manipulates the authorization response and substitutes their code (bound to their identity) for the victim's code. This code is then exchanged by the client for an access token, which in turn is accepted by the identity API, since the audience, with respect to the resource server, is correct. But since the identifier returned by the identity API is determined by the identity in the access token (issued based on the victim's code), the attacker is logged into the target application under the victim's identity.
それぞれのID APIの「コード」。悪意のあるアプリはこのコードを攻撃者に送信し、攻撃者はターゲットアプリケーション内のログインプロセスをトリガーします。攻撃者は認証応答を操作し、被害者のコードを（自分のIDにバインドされた）コードに置き換えます。次に、このコードはクライアントによってアクセストークンと交換されます。アクセストークンは、リソースサーバーに関する対象ユーザーが正しいため、ID APIによって受け入れられます。ただし、ID APIによって返される識別子は、アクセストークン（被害者のコードに基づいて発行される）のIDによって決定されるため、攻撃者は被害者のIDでターゲットアプリケーションにログインします。
Impact: The attacker gains access to an application and user-specific data within the application.
影響：攻撃者は、アプリケーションおよびアプリケーション内のユーザー固有のデータにアクセスできます。
Countermeasures:
対応策：
o All clients must indicate their client ids with every request to exchange an authorization "code" for an access token. The authorization server must validate whether the particular authorization "code" has been issued to the particular client. If possible, the client shall be authenticated beforehand.
o すべてのクライアントは、認証「コード」をアクセストークンと交換するすべてのリクエストでクライアントIDを示す必要があります。許可サーバーは、特定の許可「コード」が特定のクライアントに発行されたかどうかを検証する必要があります。可能であれば、クライアントは事前に認証されます。
o Clients should use an appropriate protocol, such as OpenID (cf. [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to implement user login. Both support audience restrictions on clients.
o クライアントは、OpenID（[OPENID]を参照）またはSAML（[OASIS.sstc-saml-bindings-1.1]を参照）などの適切なプロトコルを使用して、ユーザーログインを実装する必要があります。どちらもクライアントの視聴者制限をサポートしています。
In the implicit grant type flow, the access token is directly returned to the client as a fragment part of the redirect URI. It is assumed that the token is not sent to the redirect URI target, as HTTP user agents do not send the fragment part of URIs to HTTP servers. Thus, an attacker cannot eavesdrop the access token on this communication path, and the token cannot leak through HTTP referrer headers.
暗黙的な付与タイプのフローでは、アクセストークンはリダイレクトURIのフラグメント部分としてクライアントに直接返されます。 HTTPユーザーエージェントはURIのフラグメント部分をHTTPサーバーに送信しないため、トークンはリダイレクトURIターゲットに送信されないことが前提となっています。したがって、攻撃者はこの通信パスでアクセストークンを盗聴できず、トークンはHTTPリファラーヘッダーを介して漏洩できません。
This token might be eavesdropped by an attacker. The token is sent from the server to the client via a URI fragment of the redirect URI. If the communication is not secured or the endpoint is not secured, the token could be leaked by parsing the returned URI.
このトークンは、攻撃者によって盗聴される可能性があります。トークンは、リダイレクトURIのURIフラグメントを介してサーバーからクライアントに送信されます。通信が保護されていないか、エンドポイントが保護されていない場合、返されたURIを解析することでトークンが漏洩する可能性があります。
Impact: The attacker would be able to assume the same rights granted by the token.
影響：攻撃者は、トークンによって付与されたものと同じ権限を引き継ぐことができます。
Countermeasures:
対応策：
o The authorization server should ensure confidentiality (e.g., using TLS) of the response from the authorization server to the client (see Section 5.1.1).
o 承認サーバーは、承認サーバーからクライアントへの応答の機密性（TLSの使用など）を保証する必要があります（セクション5.1.1を参照）。
An attacker could obtain the token from the browser's history. Note that this means the attacker needs access to the particular device.
攻撃者は、ブラウザの履歴からトークンを入手する可能性があります。これは、攻撃者が特定のデバイスにアクセスする必要があることを意味することに注意してください。
Countermeasures:
対応策：
o Use short expiry time for tokens (see Section 5.1.5.3). Reduced scope of the token may reduce the impact of that attack (see Section 5.1.5.1).
o トークンには短い有効期限を使用します（セクション5.1.5.3を参照）。トークンのスコープを小さくすると、その攻撃の影響が小さくなる場合があります（セクション5.1.5.1を参照）。
o Make responses non-cacheable.
o 応答をキャッシュ不可にします。
A malicious client could attempt to obtain a token by fraud.
悪意のあるクライアントが詐欺でトークンを取得しようとする可能性があります。
The same countermeasures as for Section 4.4.1.4 are applicable, except client authentication.
クライアント認証を除き、4.4.1.4項と同じ対策を適用できます。
A hostile party could act as the client web server and replace or modify the actual implementation of the client (script). This could be achieved using DNS or ARP spoofing. This applies to clients implemented within the web browser in a scripting language.
敵対者は、クライアントWebサーバーとして機能し、クライアント（スクリプト）の実際の実装を置き換えたり変更したりできます。これは、DNSまたはARPスプーフィングを使用して実現できます。これは、スクリプト言語でWebブラウザー内に実装されたクライアントに適用されます。
Impact: The attacker could obtain user credential information and assume the full identity of the user.
影響：攻撃者はユーザーの資格情報を取得し、ユーザーの完全なIDを取得する可能性があります。
Countermeasures:
対応策：
o The authorization server should authenticate the server from which scripts are obtained (see Section 5.1.2).
o 認可サーバーは、スクリプトを取得するサーバーを認証する必要があります（セクション5.1.2を参照）。
o The client should ensure that scripts obtained have not been altered in transport (see Section 5.1.1).
o クライアントは、取得したスクリプトがトランスポートで変更されていないことを確認する必要があります（セクション5.1.1を参照）。
o Introduce one-time, per-use secrets (e.g., "client_secret") values that can only be used by scripts in a small time window once loaded from a server. The intention would be to reduce the effectiveness of copying client-side scripts for re-use in an attacker's modified code.
o サーバーから一度読み込まれると、小さな時間枠内のスクリプトでのみ使用できる、1回限りの使用ごとのシークレット（「client_secret」など）の値を導入します。意図は、攻撃者の変更されたコードで再利用するためにクライアント側のスクリプトをコピーする効果を減らすことです。
CSRF attacks (see Section 4.4.1.8) also work against the redirect URI used in the implicit grant flow. An attacker could acquire an access token to their own protected resources. He could then construct a redirect URI and embed their access token in that URI. If he can trick the user into following the redirect URI and the client does not have protection against this attack, the user may have the attacker's access token authorized within their client.
CSRF攻撃（セクション4.4.1.8を参照）は、暗黙の許可フローで使用されるリダイレクトURIに対しても機能します。攻撃者は自分の保護されたリソースへのアクセストークンを取得する可能性があります。その後、リダイレクトURIを作成し、そのURIにアクセストークンを埋め込むことができます。ユーザーをだましてリダイレクトURIをたどることができ、クライアントにこの攻撃に対する保護がない場合、ユーザーは攻撃者のアクセストークンをクライアント内で承認されている可能性があります。
Impact: The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker's resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker's identity at the external Identity Provider. In this way, the attacker could easily access the victim's data at the client by logging in from another device with his credentials at the external Identity Provider.
影響：ユーザーは攻撃者に代わってリソースにアクセスします。効果的な影響は、アクセスされるリソースのタイプによって異なります。たとえば、ユーザーがプライベートアイテムを攻撃者のリソースにアップロードする可能性があります。または、サードパーティのログインシナリオでOAuthを使用する場合、ユーザーは自分のクライアントアカウントを外部IDプロバイダーの攻撃者のIDに関連付けることができます。このようにして、攻撃者は外部のアイデンティティプロバイダーに自分の資格情報を使用して別のデバイスからログインすることにより、クライアントで被害者のデータに簡単にアクセスできます。
Countermeasures:
対応策：
o The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token. This will ensure that the client is not tricked into completing any redirect callback unless it is linked to an authorization request initiated by the client. The "state" parameter should not be guessable, and the client should be capable of keeping the "state" parameter secret.
o 「state」パラメータを使用して、認証リクエストをアクセストークンの配信に使用されるリダイレクトURIにリンクする必要があります。これにより、クライアントが開始した認証要求にリンクされていない限り、クライアントがだまされてリダイレクトコールバックが完了しないようになります。 「状態」パラメーターは推測可能であってはならず、クライアントは「状態」パラメーターを秘密に保つことができる必要があります。
o Client developers and end users can be educated to not follow untrusted URLs.
o クライアント開発者とエンドユーザーは、信頼できないURLをたどらないように教育することができます。
An attacker could attempt to log into an application or web site using a victim's identity. Applications relying on identity data provided by an OAuth protected service API to login users are vulnerable to this threat. This pattern can be found in so-called "social login" scenarios.
攻撃者は、被害者のIDを使用してアプリケーションまたはWebサイトへのログインを試みる可能性があります。 OAuthで保護されたサービスAPIがユーザーにログインするために提供するIDデータに依存するアプリケーションは、この脅威に対して脆弱です。このパターンは、いわゆる「ソーシャルログイン」シナリオで見られます。
As a prerequisite, a resource server offers an API to obtain personal information about a user that could be interpreted as having obtained a user identity. In this sense, the client is treating the resource server API as an "identity" API. A client utilizes OAuth to obtain an access token for the identity API. It then queries the identity API for an identifier and uses it to look up its internal user account data (login). The client assumes that, because it was able to obtain information about the user, the user has been authenticated.
前提条件として、リソースサーバーは、ユーザーIDを取得したと解釈できるユーザーに関する個人情報を取得するAPIを提供します。この意味で、クライアントはリソースサーバーAPIを「ID」APIとして扱います。クライアントはOAuthを使用してID APIのアクセストークンを取得します。次に、ID APIに識別子を照会し、それを使用して内部ユーザーアカウントデータを検索します（ログイン）。クライアントは、ユーザーに関する情報を取得できたため、ユーザーが認証されたと想定しています。
To succeed, the attacker needs to gather a valid access token of the respective victim from the same Identity Provider used by the target client application. The attacker tricks the victim into logging into a malicious app (which may appear to be legitimate to the Identity Provider) using the same Identity Provider as the target application. This results in the Identity Provider's authorization server issuing an access token for the respective identity API. The malicious app then sends this access token to the attacker, which in turn triggers a login process within the target application. The attacker now manipulates the authorization response and substitutes their access token (bound to their identity) for the victim's access token. This token is accepted by the identity API, since the audience, with respect to the resource server, is correct. But since the identifier returned by the identity API is determined by the identity in the access token, the attacker is logged into the target application under the victim's identity.
攻撃者が成功するには、ターゲットクライアントアプリケーションで使用されているものと同じアイデンティティプロバイダーから、それぞれの被害者の有効なアクセストークンを収集する必要があります。攻撃者は、標的のアプリケーションと同じIDプロバイダーを使用して、被害者をだまして悪意のあるアプリ（IDプロバイダーに正当であるように見える）にログインさせます。これにより、IDプロバイダーの承認サーバーがそれぞれのID APIのアクセストークンを発行します。悪意のあるアプリはこのアクセストークンを攻撃者に送信し、攻撃者はターゲットアプリケーション内のログインプロセスをトリガーします。攻撃者は認証応答を操作して、被害者のアクセストークンを（IDにバインドされた）アクセストークンに置き換えます。リソースサーバーに関する対象者が正しいため、このトークンはID APIによって受け入れられます。ただし、ID APIによって返されるIDはアクセストークンのIDによって決定されるため、攻撃者は被害者のIDでターゲットアプリケーションにログインします。
Impact: The attacker gains access to an application and user-specific data within the application.
影響：攻撃者は、アプリケーションおよびアプリケーション内のユーザー固有のデータにアクセスできます。
Countermeasures:
対応策：
o Clients should use an appropriate protocol, such as OpenID (cf. [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to implement user login. Both support audience restrictions on clients.
o クライアントは、OpenID（[OPENID]を参照）またはSAML（[OASIS.sstc-saml-bindings-1.1]を参照）などの適切なプロトコルを使用して、ユーザーログインを実装する必要があります。どちらもクライアントの視聴者制限をサポートしています。
The resource owner password credentials grant type (see [RFC6749], Section 4.3), often used for legacy/migration reasons, allows a client to request an access token using an end-user's user id and password along with its own credential. This grant type has higher risk because it maintains the UID/password anti-pattern. Additionally, because the user does not have control over the authorization process, clients using this grant type are not limited by scope but instead have potentially the same capabilities as the user themselves. As there is no authorization step, the ability to offer token revocation is bypassed.
リソース所有者のパスワード資格情報付与タイプ（[RFC6749]、セクション4.3を参照）は、レガシー/移行の理由でよく使用され、クライアントはエンドユーザーのユーザーIDとパスワード、および独自の資格情報を使用してアクセストークンをリクエストできます。この付与タイプは、UID /パスワードのアンチパターンを維持するため、リスクが高くなります。さらに、ユーザーは承認プロセスを制御できないため、この付与タイプを使用するクライアントはスコープによって制限されず、ユーザー自身と同じ機能を持つ可能性があります。承認手順がないため、トークンの取り消しを提供する機能はバイパスされます。
Because passwords are often used for more than 1 service, this anti-pattern may also put at risk whatever else is accessible with the supplied credential. Additionally, any easily derived equivalent (e.g., joe@example.com and joe@example.net) might easily allow someone to guess that the same password can be used elsewhere.
パスワードは複数のサービスで使用されることが多いため、このアンチパターンは、提供された資格情報で他にアクセス可能なものを危険にさらす可能性があります。さらに、簡単に導出できる同等のもの（たとえば、joe @ example.comやjoe@example.net）は、同じパスワードが他の場所で使用されていると誰かが簡単に推測できるようにする可能性があります。
Impact: The resource server can only differentiate scope based on the access token being associated with a particular client. The client could also acquire long-lived tokens and pass them up to an attacker's web service for further abuse. The client, eavesdroppers, or endpoints could eavesdrop the user id and password.
影響：リソースサーバーは、特定のクライアントに関連付けられているアクセストークンに基づいてのみスコープを区別できます。クライアントは、存続期間の長いトークンを取得し、さらに悪用するために攻撃者のWebサービスに渡すこともできます。クライアント、盗聴者、またはエンドポイントがユーザーIDとパスワードを盗聴する可能性があります。
Countermeasures:
対応策：
o Except for migration reasons, minimize use of this grant type.
o 移行の理由を除いて、この付与タイプの使用を最小限に抑えます。
o The authorization server should validate the client id associated with the particular refresh token with every refresh request (Section 5.2.2.2).
o 承認サーバーは、すべての更新要求で特定の更新トークンに関連付けられたクライアントIDを検証する必要があります（セクション5.2.2.2）。
o As per the core OAuth specification, the authorization server must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1).
o コアOAuth仕様に従って、承認サーバーはこれらの送信がTLSなどのトランスポート層メカニズムを使用して保護されていることを確認する必要があります（セクション5.1.1を参照）。
o Rather than encouraging users to use a UID and password, service providers should instead encourage users not to use the same password for multiple services.
o サービスプロバイダーは、ユーザーにUIDとパスワードの使用を奨励するのではなく、複数のサービスに同じパスワードを使用しないようユーザーに奨励すべきです。
o Limit use of resource owner password credential grants to scenarios where the client application and the authorizing service are from the same organization.
o リソース所有者のパスワード資格情報付与の使用を、クライアントアプリケーションと承認サービスが同じ組織のものであるシナリオに制限します。
If the client does not provide enough protection, an attacker or disgruntled employee could retrieve the passwords for a user.
クライアントが十分な保護を提供しない場合、攻撃者または不満を持つ従業員がユーザーのパスワードを取得する可能性があります。
Countermeasures:
対応策：
o Use other flows that do not rely on the client's cooperation for secure resource owner credential handling.
o 安全なリソース所有者の資格情報の処理について、クライアントの協力に依存しない他のフローを使用します。
o Use digest authentication instead of plaintext credential processing.
o プレーンテキストの資格情報処理の代わりにダイジェスト認証を使用します。
o Obfuscate passwords in logs.
o ログ内のパスワードを難読化します。
All interaction with the resource owner is performed by the client. Thus it might, intentionally or unintentionally, happen that the client obtains a token with scope unknown for, or unintended by, the resource owner. For example, the resource owner might think the client needs and acquires read-only access to its media storage only but the client tries to acquire an access token with full access permissions.
リソース所有者とのすべての対話は、クライアントによって実行されます。したがって、意図的または非意図的に、クライアントがリソース所有者にとってスコープが不明または意図しないスコープを持つトークンを取得する可能性があります。たとえば、リソース所有者は、クライアントがメディアストレージへの読み取り専用アクセスのみを必要とし、それを取得すると考えても、クライアントは完全なアクセス許可を持つアクセストークンを取得しようとします。
Countermeasures:
対応策：
o Use other flows that do not rely on the client's cooperation for resource owner interaction.
o リソース所有者との対話には、クライアントの協力に依存しない他のフローを使用してください。
o The authorization server may generally restrict the scope of access tokens (Section 5.1.5.1) issued by this flow. If the particular client is trustworthy and can be authenticated in a reliable way, the authorization server could relax that restriction. Resource owners may prescribe (e.g., in their preferences) what the maximum scope is for clients using this flow.
o 認可サーバーは、通常、このフローによって発行されるアクセストークンの範囲（5.1.5.1節）を制限する場合があります。特定のクライアントが信頼でき、信頼できる方法で認証できる場合、承認サーバーはその制限を緩和できます。リソース所有者は、このフローを使用するクライアントの最大スコープを（たとえば、プリファレンスで）規定できます。
o The authorization server could notify the resource owner by an appropriate medium, e.g., email, of the grant issued (see Section 5.1.3).
o 許可サーバーは、発行された許可を適切な媒体（Eメールなど）でリソース所有者に通知できます（セクション5.1.3を参照）。
4.4.3.3. Threat: Client Obtains Refresh Token through Automatic Authorization
4.4.3.3. 脅威：クライアントが自動認証を通じて更新トークンを取得
All interaction with the resource owner is performed by the client. Thus it might, intentionally or unintentionally, happen that the client obtains a long-term authorization represented by a refresh token even if the resource owner did not intend so.
リソース所有者とのすべての対話は、クライアントによって実行されます。したがって、リソース所有者が意図していない場合でも、意図的または非意図的に、クライアントが更新トークンによって表される長期間の承認を取得することがあります。
Countermeasures:
対応策：
o Use other flows that do not rely on the client's cooperation for resource owner interaction.
o リソース所有者との対話には、クライアントの協力に依存しない他のフローを使用してください。
o The authorization server may generally refuse to issue refresh tokens in this flow (see Section 5.2.2.1). If the particular client is trustworthy and can be authenticated in a reliable way (see client authentication), the authorization server could relax that restriction. Resource owners may allow or deny (e.g., in their preferences) the issuing of refresh tokens using this flow as well.
o認可サーバーは通常、このフローで更新トークンの発行を拒否する場合があります（セクション5.2.2.1を参照）。特定のクライアントが信頼でき、信頼できる方法で認証できる場合（クライアント認証を参照）、許可サーバーはその制限を緩和できます。リソース所有者は、このフローを使用して、リフレッシュトークンの発行を（たとえば、プリファレンスで）許可または拒否することもできます。
o The authorization server could notify the resource owner by an appropriate medium, e.g., email, of the refresh token issued (see Section 5.1.3).
o 認可サーバーは、発行された更新トークンを適切な媒体（電子メールなど）でリソース所有者に通知できます（セクション5.1.3を参照）。
An attacker could attempt to eavesdrop the transmission of end-user credentials with the grant type "password" between the client and server.
攻撃者は、クライアントとサーバー間のエンドユーザー資格情報の許可タイプ「パスワード」の送信を盗聴する可能性があります。
Impact: Disclosure of a single end-user's password.
影響：単一のエンドユーザーのパスワードの開示。
Countermeasures:
対応策：
o Ensure confidentiality of requests (Section 5.1.1).
o リクエストの機密性を確保します（セクション5.1.1）。
o Use alternative authentication means that do not require the sending of plaintext credentials over the wire (e.g., Hash-based Message Authentication Code).
o 代替認証を使用することは、平文の資格情報をネットワーク経由で送信する必要がないことを意味します（たとえば、ハッシュベースのメッセージ認証コード）。
4.4.3.5. Threat: Obtaining User Passwords from Authorization Server Database
4.4.3.5. 脅威：承認サーバーデータベースからのユーザーパスワードの取得
An attacker may obtain valid username/password combinations from the authorization server's database by gaining access to the database or launching a SQL injection attack.
攻撃者は、データベースへのアクセスを取得するか、SQLインジェクション攻撃を開始することにより、認証サーバーのデータベースから有効なユーザー名/パスワードの組み合わせを取得する可能性があります。
Impact: Disclosure of all username/password combinations. The impact may exceed the domain of the authorization server, since many users tend to use the same credentials on different services.
影響：すべてのユーザー名とパスワードの組み合わせの開示。多くのユーザーが異なるサービスで同じ資格情報を使用する傾向があるため、影響は承認サーバーのドメインを超える可能性があります。
Countermeasures:
対応策：
o Enforce credential storage protection best practices (Section 5.1.4.1).
o 資格情報ストレージ保護のベストプラクティスを実施します（セクション5.1.4.1）。
An attacker may try to guess valid username/password combinations using the grant type "password".
攻撃者は、付与タイプ「パスワード」を使用して、有効なユーザー名/パスワードの組み合わせを推測しようとする可能性があります。
Impact: Revelation of a single username/password combination.
影響：単一のユーザー名/パスワードの組み合わせの暴露。
Countermeasures:
対応策：
o Utilize secure password policy (Section 5.1.4.2.1).
o 安全なパスワードポリシーを使用します（セクション5.1.4.2.1）。
o Lock accounts (Section 5.1.4.2.3).
o アカウントをロックします（セクション5.1.4.2.3）。
o Use tar pit (Section 5.1.4.2.4).
o 彼にピットを配線します（セクション5.1.4.2.4）。
o Use CAPTCHAs (Section 5.1.4.2.5).
o CAPTCHAを使用します（セクション5.1.4.2.5）。
o Consider not using the grant type "password".
o 付与タイプ「パスワード」を使用しないことを検討してください。
o Client authentication (see Section 5.2.3) will provide another authentication factor and thus hinder the attack.
o クライアント認証（セクション5.2.3を参照）は別の認証要素を提供し、攻撃を妨害します。
Client credentials (see [RFC6749], Section 3) consist of an identifier (not secret) combined with an additional means (such as a matching client secret) of authenticating a client. The threats to this grant type are similar to those described in Section 4.4.3.
クライアント認証情報（[RFC6749]のセクション3を参照）は、クライアントを認証するための追加の手段（一致するクライアントシークレットなど）と組み合わされた識別子（シークレットではない）で構成されます。この付与タイプに対する脅威は、セクション4.4.3で説明したものと同様です。
An attacker may eavesdrop refresh tokens when they are transmitted from the authorization server to the client.
攻撃者は、承認サーバーからクライアントに送信された更新トークンを盗聴する可能性があります。
Countermeasures:
対応策：
o As per the core OAuth spec, the authorization servers must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1).
o コアOAuth仕様に従って、承認サーバーはこれらの送信がTLSなどのトランスポート層メカニズムを使用して保護されていることを確認する必要があります（セクション5.1.1を参照）。
o If end-to-end confidentiality cannot be guaranteed, reducing scope (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for issued access tokens can be used to reduce the damage in case of leaks.
o エンドツーエンドの機密性を保証できない場合は、漏洩した場合の被害を軽減するために、発行されたアクセストークンのスコープ（5.1.5.1を参照）と有効期限（5.1.5.3を参照）を削減することができます。
4.5.2. Threat: Obtaining Refresh Token from Authorization Server Database
4.5.2. 脅威：承認サーバーデータベースからの更新トークンの取得
This threat is applicable if the authorization server stores refresh tokens as handles in a database. An attacker may obtain refresh tokens from the authorization server's database by gaining access to the database or launching a SQL injection attack.
この脅威は、承認サーバーがリフレッシュトークンをデータベースのハンドルとして保存している場合に発生します。攻撃者は、データベースへのアクセスを取得するか、SQLインジェクション攻撃を開始することにより、承認サーバーのデータベースから更新トークンを取得する可能性があります。
Impact: Disclosure of all refresh tokens.
影響：すべての更新トークンの開示。
Countermeasures:
対応策：
o Enforce credential storage protection best practices (Section 5.1.4.1).
o 資格情報ストレージ保護のベストプラクティスを実施します（セクション5.1.4.1）。
o Bind token to client id, if the attacker cannot obtain the required id and secret (Section 5.1.5.8).
o 攻撃者が必要なIDとシークレットを取得できない場合は、トークンをクライアントIDにバインドします（5.1.5.8項）。
An attacker may try to guess valid refresh token values and send it using the grant type "refresh_token" in order to obtain a valid access token.
攻撃者は有効な更新トークンの値を推測し、有効なアクセストークンを取得するために、許可タイプ「refresh_token」を使用してそれを送信する可能性があります。
Impact: Exposure of a single refresh token and derivable access tokens.
影響：単一の更新トークンと派生可能なアクセストークンの公開。
Countermeasures:
対応策：
o For handle-based designs (Section 5.1.4.2.2).
o ハンドルベースのデザイン（セクション5.1.4.2.2）。
o For assertion-based designs (Section 5.1.5.9).
o アサーションベースのデザインの場合（セクション5.1.5.9）。
o Bind token to client id, because the attacker would guess the matching client id, too (see Section 5.1.5.8).
o 攻撃者も一致するクライアントIDを推測するため、トークンをクライアントIDにバインドします（セクション5.1.5.8を参照）。
o Authenticate the client; this adds another element that the attacker has to guess (see Section 5.2.3.4).
o クライアントを認証します。これにより、攻撃者が推測しなければならない別の要素が追加されます（セクション5.2.3.4を参照）。
4.5.4. Threat: Refresh Token Phishing by Counterfeit Authorization Server
4.5.4. 脅威：偽造認証サーバーによるトークンフィッシングの更新
An attacker could try to obtain valid refresh tokens by proxying requests to the authorization server. Given the assumption that the authorization server URL is well-known at development time or can at least be obtained from a well-known resource server, the attacker must utilize some kind of spoofing in order to succeed.
攻撃者は、承認サーバーにリクエストをプロキシすることにより、有効な更新トークンを取得しようとする可能性があります。承認サーバーのURLは開発時によく知られているか、少なくともよく知られているリソースサーバーから取得できると想定すると、攻撃者は成功するために何らかのスプーフィングを利用する必要があります。
Countermeasures:
対応策：
o Utilize server authentication (as described in Section 5.1.2).
o サーバー認証を使用します（セクション5.1.2で説明）。
An attacker could try to obtain a valid access token on transport between the client and resource server. As access tokens are shared secrets between the authorization server and resource server, they should be treated with the same care as other credentials (e.g., end-user passwords).
攻撃者は、クライアントとリソースサーバー間のトランスポートで有効なアクセストークンを取得しようとする可能性があります。アクセストークンは承認サーバーとリソースサーバーの間で共有されるシークレットであるため、他の資格情報（エンドユーザーのパスワードなど）と同じように扱う必要があります。
Countermeasures:
対応策：
o Access tokens sent as bearer tokens should not be sent in the clear over an insecure channel. As per the core OAuth spec, transmission of access tokens must be protected using transport-layer mechanisms such as TLS (see Section 5.1.1).
o ベアラートークンとして送信されたアクセストークンは、安全でないチャネルを介して平文で送信しないでください。コアOAuth仕様に従って、アクセストークンの送信は、TLSなどのトランスポート層メカニズムを使用して保護する必要があります（セクション5.1.1を参照）。
o A short lifetime reduces impact in case tokens are compromised (see Section 5.1.5.3).
o 有効期間が短いと、トークンが侵害された場合の影響が減少します（セクション5.1.5.3を参照）。
o The access token can be bound to a client's identifier and require the client to prove legitimate ownership of the token to the resource server (see Section 5.4.2).
o アクセストークンはクライアントの識別子にバインドでき、クライアントがリソースサーバーに対してトークンの正当な所有権を証明することを要求できます（セクション5.4.2を参照）。
An attacker could attempt to replay valid requests in order to obtain or to modify/destroy user data.
攻撃者は、ユーザーデータを取得または変更/破棄するために、有効なリクエストを再生しようとする可能性があります。
Countermeasures:
対応策：
o The resource server should utilize transport security measures (e.g., TLS) in order to prevent such attacks (see Section 5.1.1). This would prevent the attacker from capturing valid requests.
o リソースサーバーは、このような攻撃を防止するために、トランスポートセキュリティ対策（TLSなど）を利用する必要があります（セクション5.1.1を参照）。これにより、攻撃者は有効なリクエストをキャプチャできなくなります。
o Alternatively, the resource server could employ signed requests (see Section 5.4.3) along with nonces and timestamps in order to uniquely identify requests. The resource server should detect and refuse every replayed request.
o あるいは、リソースサーバーは、リクエストを一意に識別するために、ナンスとタイムスタンプとともに署名付きリクエスト（セクション5.4.3を参照）を使用できます。リソースサーバーは、再生されたすべての要求を検出して拒否する必要があります。
Where the token is a handle, the attacker may attempt to guess the access token values based on knowledge they have from other access tokens.
トークンがハンドルである場合、攻撃者は他のアクセストークンから得た知識に基づいてアクセストークンの値を推測する可能性があります。
Impact: Access to a single user's data.
影響：単一のユーザーのデータへのアクセス。
Countermeasures:
対応策：
o Handle tokens should have a reasonable level of entropy (see Section 5.1.4.2.2) in order to make guessing a valid token value infeasible.
o 有効なトークン値の推測を実行不可能にするために、ハンドルトークンには妥当なレベルのエントロピー（セクション5.1.4.2.2を参照）が必要です。
o Assertion (or self-contained token) token contents should be protected by a digital signature (see Section 5.1.5.9).
o アサーション（または自己完結型トークン）トークンの内容は、デジタル署名で保護する必要があります（セクション5.1.5.9を参照）。
o Security can be further strengthened by using a short access token duration (see Sections 5.1.5.2 and 5.1.5.3).
o 短いアクセストークン期間を使用すると、セキュリティをさらに強化できます（セクション5.1.5.2および5.1.5.3を参照）。
An attacker may pretend to be a particular resource server and to accept tokens from a particular authorization server. If the client sends a valid access token to this counterfeit resource server, the server in turn may use that token to access other services on behalf of the resource owner.
攻撃者は、特定のリソースサーバーになりすまして、特定の承認サーバーからのトークンを受け入れるふりをする可能性があります。クライアントが有効なアクセストークンをこの偽造リソースサーバーに送信すると、サーバーはそのトークンを使用して、リソース所有者に代わって他のサービスにアクセスできます。
Countermeasures:
対応策：
o Clients should not make authenticated requests with an access token to unfamiliar resource servers, regardless of the presence of a secure channel. If the resource server URL is well-known to the client, it may authenticate the resource servers (see Section 5.1.2).
o クライアントは、セキュリティで保護されたチャネルの存在に関係なく、見慣れないリソースサーバーへのアクセストークンを使用して認証された要求を行わないでください。リソースサーバーのURLがクライアントに既知の場合、リソースサーバーを認証する場合があります（セクション5.1.2を参照）。
o Associate the endpoint URL of the resource server the client talked to with the access token (e.g., in an audience field) and validate the association at a legitimate resource server. The endpoint URL validation policy may be strict (exact match) or more relaxed (e.g., same host). This would require telling the authorization server about the resource server endpoint URL in the authorization process.
o クライアントが通信したリソースサーバーのエンドポイントURLをアクセストークン（たとえば、対象ユーザーフィールド内）に関連付け、正当なリソースサーバーで関連付けを検証します。エンドポイントURL検証ポリシーは、厳密（完全一致）またはより緩和（同じホストなど）にすることができます。これには、承認プロセスでリソースサーバーのエンドポイントURLを承認サーバーに通知する必要があります。
o Associate an access token with a client and authenticate the client with resource server requests (typically via a signature, in order to not disclose a secret to a potential attacker). This prevents the attack because the counterfeit server is assumed to lack the capability to correctly authenticate on behalf of the legitimate client to the resource server (Section 5.4.2).
o アクセストークンをクライアントに関連付け、クライアントをリソースサーバー要求で認証します（通常、潜在的な攻撃者に秘密を開示しないために、署名を介して）。これにより、偽造サーバーは正当なクライアントに代わってリソースサーバーに正しく認証する機能がないと想定されるため、攻撃を防ぐことができます（セクション5.4.2）。
o Restrict the token scope (see Section 5.1.5.1) and/or limit the token to a certain resource server (Section 5.1.5.5).
o トークンのスコープを制限するか（セクション5.1.5.1を参照）、トークンを特定のリソースサーバーに制限します（セクション5.1.5.5）。
A legitimate resource server could attempt to use an access token to access another resource server. Similarly, a client could try to use a token obtained for one server on another resource server.
正当なリソースサーバーがアクセストークンを使用して別のリソースサーバーにアクセスしようとする可能性があります。同様に、クライアントは、あるサーバー用に取得したトークンを別のリソースサーバーで使用しようとする可能性があります。
Countermeasures:
対応策：
o Tokens should be restricted to particular resource servers (see Section 5.1.5.5).
o トークンは特定のリソースサーバーに制限する必要があります（セクション5.1.5.5を参照）。
An OAuth HTTP authentication scheme as discussed in [RFC6749] is optional. However, [RFC2616] relies on the Authorization and WWW-Authenticate headers to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these headers. For example, private authenticated content may be stored in (and thus be retrievable from) publicly accessible caches.
[RFC6749]で説明されているOAuth HTTP認証スキームはオプションです。ただし、[RFC2616]はAuthorizationヘッダーとWWW-Authenticateヘッダーに依存して、認証されたコンテンツを区別し、保護できるようにします。特に、プロキシとキャッシュは、これらのヘッダーを使用しないリクエストを適切に保護できない場合があります。たとえば、プライベートな認証済みコンテンツは、パブリックにアクセス可能なキャッシュに格納されている（したがって、そこから取得できる）場合があります。
Countermeasures:
対応策：
o Clients and resource servers not using an OAuth HTTP authentication scheme (see Section 5.4.1) should take care to use Cache-Control headers to minimize the risk that authenticated content is not protected. Such clients should send a Cache-Control header containing the "no-store" option [RFC2616]. Resource server success (2XX status) responses to these requests should contain a Cache-Control header with the "private" option [RFC2616].
o OAuth HTTP認証スキーム（セクション5.4.1を参照）を使用していないクライアントとリソースサーバーは、キャッシュされた制御ヘッダーを使用して、認証されたコンテンツが保護されないリスクを最小限に抑えるように注意する必要があります。このようなクライアントは、「ストアなし」オプションを含むCache-Controlヘッダーを送信する必要があります[RFC2616]。これらのリクエストに対するリソースサーバーの成功（2XXステータス）応答には、「プライベート」オプションを備えたCache-Controlヘッダーが含まれている必要があります[RFC2616]。
o Reducing scope (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access tokens can be used to reduce the damage in case of leaks.
o アクセストークンのスコープ（5.1.5.1を参照）と有効期限（5.1.5.3を参照）を減らすことで、リークが発生した場合の損傷を減らすことができます。
If access tokens are sent via URI query parameters, such tokens may leak to log files and the HTTP "referer".
アクセストークンがURIクエリパラメータを介して送信される場合、そのようなトークンはログファイルとHTTPの「参照元」にリークする可能性があります。
Countermeasures:
対応策：
o Use Authorization headers or POST parameters instead of URI request parameters (see Section 5.4.1).
o URI要求パラメーターの代わりに、AuthorizationヘッダーまたはPOSTパラメーターを使用します（セクション5.4.1を参照）。
o Set logging configuration appropriately.
o ロギング構成を適切に設定します。
o Prevent unauthorized persons from access to system log files (see Section 5.1.4.1.1).
o 権限のない人がシステムログファイルにアクセスできないようにします（セクション5.1.4.1.1を参照）。
o Abuse of leaked access tokens can be prevented by enforcing authenticated requests (see Section 5.4.2).
o 認証されたリクエストを強制することで、漏洩したアクセストークンの悪用を防ぐことができます（セクション5.4.2を参照）。
o The impact of token leakage may be reduced by limiting scope (see Section 5.1.5.1) and duration (see Section 5.1.5.3) and by enforcing one-time token usage (see Section 5.1.5.4).
o トークンリーケージの影響は、スコープ（セクション5.1.5.1を参照）と期間（セクション5.1.5.3を参照）を制限し、ワンタイムトークンの使用（セクション5.1.5.4を参照）を適用することで軽減できます。
This section describes the countermeasures as recommended to mitigate the threats described in Section 4.
このセクションでは、セクション4で説明した脅威を軽減するために推奨される対策について説明します。
This section covers considerations that apply generally across all OAuth components (client, resource server, token server, and user agents).
このセクションでは、すべてのOAuthコンポーネント（クライアント、リソースサーバー、トークンサーバー、ユーザーエージェント）に一般的に適用される考慮事項について説明します。
This is applicable to all requests sent from the client to the authorization server or resource server. While OAuth provides a mechanism for verifying the integrity of requests, it provides no guarantee of request confidentiality. Unless further precautions are taken, eavesdroppers will have full access to request content and may be able to mount interception or replay attacks by using the contents of requests, e.g., secrets or tokens.
これは、クライアントから許可サーバーまたはリソースサーバーに送信されるすべての要求に適用されます。 OAuthはリクエストの整合性を検証するメカニズムを提供しますが、リクエストの機密性は保証しません。さらなる予防措置が講じられない限り、盗聴者はリクエストのコンテンツに完全にアクセスでき、リクエストのコンテンツ（シークレットやトークンなど）を使用して、傍受やリプレイ攻撃を開始できる可能性があります。
Attacks can be mitigated by using transport-layer mechanisms such as TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec VPNs [RFC4301], may be considered as well.
攻撃は、TLS [RFC5246]などのトランスポート層メカニズムを使用することで軽減できます。たとえば、IPsec VPN [RFC4301]に基づく仮想プライベートネットワーク（VPN）も検討できます。
Note: This document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g., on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause.
注：このドキュメントでは、それぞれのプロトコルエンティティ間のエンドツーエンドのTLS保護接続を想定しています。 TLSをオフロードすることで（データセンターエッジなどで）この想定から逸脱した展開では、これが引き起こす可能性のある追加の（主に内部関係者）脅威を説明するために、この脅威モデルを改良する必要があります。
This is a countermeasure against the following threats:
これは、次の脅威への対策です。
o Replay of access tokens obtained on the token's endpoint or the resource server's endpoint
o トークンのエンドポイントまたはリソースサーバーのエンドポイントで取得したアクセストークンの再生
o Replay of refresh tokens obtained on the token's endpoint o Replay of authorization "codes" obtained on the token's endpoint (redirect?)
oトークンのエンドポイントで取得された更新トークンの再生oトークンのエンドポイントで取得された認証「コード」の再生（リダイレクト？）
o Replay of user passwords and client secrets
o ユーザーパスワードとクライアントシークレットの再生
HTTPS server authentication or similar means can be used to authenticate the identity of a server. The goal is to reliably bind the fully qualified domain name of the server to the public key presented by the server during connection establishment (see [RFC2818]).
HTTPSサーバー認証または同様の手段を使用して、サーバーのIDを認証できます。目標は、接続の確立時にサーバーによって提示された公開鍵にサーバーの完全修飾ドメイン名を確実にバインドすることです（[RFC2818]を参照）。
The client should validate the binding of the server to its domain name. If the server fails to prove that binding, the communication is considered a man-in-the-middle attack. This security measure depends on the certification authorities the client trusts for that purpose. Clients should carefully select those trusted CAs and protect the storage for trusted CA certificates from modifications.
クライアントは、サーバーのドメイン名へのバインドを検証する必要があります。サーバーがそのバインディングを証明できない場合、通信は中間者攻撃と見なされます。このセキュリティ対策は、クライアントがその目的で信頼する証明機関に依存します。クライアントはこれらの信頼できるCAを慎重に選択し、信頼できるCA証明書のストレージを変更から保護する必要があります。
This is a countermeasure against the following threats:
これは、次の脅威への対策です。
o Spoofing
o なりすまし
o Proxying
o プロキシ
o Phishing by counterfeit servers
o 偽造サーバーによるフィッシング
Transparency to the resource owner is a key element of the OAuth protocol. The user should always be in control of the authorization processes and get the necessary information to make informed decisions. Moreover, user involvement is a further security countermeasure. The user can probably recognize certain kinds of attacks better than the authorization server. Information can be presented/exchanged during the authorization process, after the authorization process, and every time the user wishes to get informed by using techniques such as:
リソース所有者への透過性は、OAuthプロトコルの重要な要素です。ユーザーは常に承認プロセスを制御し、情報に基づいた決定を行うために必要な情報を取得する必要があります。さらに、ユーザーの関与はさらなるセキュリティ対策です。ユーザーはおそらく認証サーバーよりも特定の種類の攻撃をよりよく認識することができます。情報は、承認プロセス中、承認プロセス後、およびユーザーが次のような手法を使用して通知を受けることを望むたびに提示/交換できます。
o User consent forms.
o ユーザー同意書。
o Notification messages (e.g., email, SMS, ...). Note that notifications can be a phishing vector. Messages should be such that look-alike phishing messages cannot be derived from them.
o 通知メッセージ（電子メール、SMSなど）。通知はフィッシングの媒介となる可能性があることに注意してください。メッセージは、類似したフィッシングメッセージをそれらから取得できないようなものである必要があります。
o Activity/event logs.
o アクティビティ/イベントログ。
o User self-care applications or portals.
o ユーザーのセルフケアアプリケーションまたはポータル。
This section describes countermeasures used to protect all kinds of credentials from unauthorized access and abuse. Credentials are long-term secrets, such as client secrets and user passwords as well as all kinds of tokens (refresh and access tokens) or authorization "codes".
このセクションでは、不正なアクセスや乱用からあらゆる種類の資格情報を保護するために使用される対策について説明します。資格情報は、クライアントシークレットやユーザーパスワードなどのすべての種類のトークン（更新トークンとアクセストークン）または認証 "コード"などの長期的なシークレットです。
Administrators should undertake industry best practices to protect the storage of credentials (for example, see [OWASP]). Such practices may include but are not limited to the following sub-sections.
管理者は、資格情報のストレージを保護するための業界のベストプラクティスを実施する必要があります（たとえば、[OWASP]を参照）。このような慣行には、次のサブセクションが含まれますが、これらに限定されません。
A server system may be locked down so that no attacker may get access to sensitive configuration files and databases.
攻撃者が機密の構成ファイルやデータベースにアクセスできないように、サーバーシステムがロックダウンされる可能性があります。
If a client identifier or other authentication component is queried or compared against a SQL database, it may become possible for an injection attack to occur if parameters received are not validated before submission to the database.
クライアント識別子またはその他の認証コンポーネントが照会されるか、SQLデータベースと比較される場合、受信したパラメーターがデータベースに送信される前に検証されないと、インジェクション攻撃が発生する可能性があります。
o Ensure that server code is using the minimum database privileges possible to reduce the "surface" of possible attacks.
o サーバーコードが可能な最小限のデータベース権限を使用して、起こり得る攻撃の「表面」を減らすようにしてください。
o Avoid dynamic SQL using concatenated input. If possible, use static SQL.
o 連結入力を使用した動的SQLは避けてください。可能であれば、静的SQLを使用してください。
o When using dynamic SQL, parameterize queries using bind arguments. Bind arguments eliminate the possibility of SQL injections.
o 動的SQLを使用する場合、バインド引数を使用してクエリをパラメーター化します。バインド引数は、SQLインジェクションの可能性を排除します。
o Filter and sanitize the input. For example, if an identifier has a known format, ensure that the supplied value matches the identifier syntax rules.
o 入力をフィルタリングしてサニタイズします。たとえば、識別子の形式が既知の場合は、指定された値が識別子の構文規則に一致していることを確認してください。
The authorization server should not store credentials in clear text. Typical approaches are to store hashes instead or to encrypt credentials. If the credential lacks a reasonable entropy level (because it is a user password), an additional salt will harden the storage to make offline dictionary attacks more difficult.
許可サーバーは資格情報を平文で保管してはなりません。典型的なアプローチは、代わりにハッシュを保存するか、資格情報を暗号化することです。資格情報に適切なエントロピーレベルが不足している場合（ユーザーパスワードであるため）、追加のソルトによってストレージが強化され、オフライン辞書攻撃がより困難になります。
Note: Some authentication protocols require the authorization server to have access to the secret in the clear. Those protocols cannot be implemented if the server only has access to hashes. Credentials should be strongly encrypted in those cases.
注：一部の認証プロトコルでは、許可サーバーが秘密に平文でアクセスできる必要があります。サーバーがハッシュにのみアクセスできる場合、これらのプロトコルは実装できません。これらの場合、資格情報を強力に暗号化する必要があります。
For client applications, insecurely persisted client credentials are easy targets for attackers to obtain. Store client credentials using an encrypted persistence mechanism such as a keystore or database. Note that compiling client credentials directly into client code makes client applications vulnerable to scanning as well as difficult to administer should client credentials change over time.
クライアントアプリケーションの場合、安全でない状態で永続化されたクライアント資格情報は、攻撃者が簡単に入手できるターゲットです。キーストアやデータベースなどの暗号化された永続化メカニズムを使用してクライアント資格情報を保存します。クライアント資格情報をクライアントコードに直接コンパイルすると、クライアントアプリケーションがスキャンに対して脆弱になるだけでなく、クライアント資格情報が時間の経過とともに変化した場合の管理が困難になります。
Usage of asymmetric cryptography will free the authorization server of the obligation to manage credentials.
非対称暗号化を使用すると、認証サーバーが資格情報を管理する義務から解放されます。
The authorization server may decide to enforce a complex user password policy in order to increase the user passwords' entropy to hinder online password attacks. Note that too much complexity can increase the likelihood that users re-use passwords or write them down, or otherwise store them insecurely.
承認サーバーは、ユーザーパスワードのエントロピーを増加させてオンラインパスワード攻撃を妨害するために、複雑なユーザーパスワードポリシーを適用することを決定する場合があります。複雑すぎると、ユーザーがパスワードを再利用したり書き留めたり、安全に保管しない可能性が高まることに注意してください。
When creating secrets not intended for usage by human users (e.g., client secrets or token handles), the authorization server should include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) generated by the authorization server.
人間のユーザーによる使用を目的としていないシークレット（クライアントシークレットやトークンハンドルなど）を作成する場合、認証サーバーは、攻撃を推測するリスクを軽減するために、適度なレベルのエントロピーを含める必要があります。トークン値は128ビット以上で、承認サーバーによって生成された暗号的に強力なランダムまたは疑似乱数シーケンス（現在のベストプラクティスについては[RFC4086]を参照）から構築する必要があります。
Online attacks on passwords can be mitigated by locking the respective accounts after a certain number of failed attempts.
パスワードへのオンライン攻撃は、一定の試行が失敗した後にそれぞれのアカウントをロックすることで軽減できます。
Note: This measure can be abused to lock down legitimate service users.
注：この対策は、正当なサービスユーザーをロックダウンするために悪用される可能性があります。
The authorization server may react on failed attempts to authenticate by username/password by temporarily locking the respective account and delaying the response for a certain duration. This duration may increase with the number of failed attempts. The objective is to slow the attacker's attempts on a certain username down.
承認サーバーは、ユーザー名/パスワードによる認証の失敗した試行に対して、それぞれのアカウントを一時的にロックし、一定の時間応答を遅らせることで反応する場合があります。この期間は、失敗した試行の数に応じて増加する可能性があります。目的は、特定のユーザー名に対する攻撃者の試行を遅くすることです。
Note: This may require a more complex and stateful design of the authorization server.
注：これには、許可サーバーのより複雑でステートフルな設計が必要になる場合があります。
The idea is to prevent programs from automatically checking a huge number of passwords, by requiring human interaction.
このアイデアは、人間の操作を必要とすることにより、プログラムが膨大な数のパスワードを自動的にチェックするのを防ぐことです。
Note: This has a negative impact on user experience.
注：これは、ユーザーエクスペリエンスに悪影響を及ぼします。
The authorization server may decide to reduce or limit the scope associated with a token. The basis of this decision is out of scope; examples are:
承認サーバーは、トークンに関連付けられたスコープを削減または制限することを決定できます。この決定の根拠は範囲外です。例は次のとおりです。
o a client-specific policy, e.g., issue only less powerful tokens to public clients,
o クライアント固有のポリシー（例：強力なトークンのみをパブリッククライアントに発行する）
o a service-specific policy, e.g., it is a very sensitive service,
o サービス固有のポリシー。たとえば、非常にデリケートなサービスです。
o a resource-owner-specific setting, or
o リソース所有者固有の設定、または
o combinations of such policies and preferences.
o そのようなポリシーと設定の組み合わせ。
The authorization server may allow different scopes dependent on the grant type. For example, end-user authorization via direct interaction with the end user (authorization "code") might be considered more reliable than direct authorization via grant type "username"/"password". This means will reduce the impact of the following threats:
認可サーバーは、付与タイプに応じて異なるスコープを許可する場合があります。たとえば、エンドユーザーとの直接対話によるエンドユーザー認証（認証 "コード"）は、付与タイプ "ユーザー名" / "パスワード"による直接認証よりも信頼性が高いと考えられます。つまり、次の脅威の影響が軽減されます。
o token leakage
o トークンの漏洩
o token issuance to malicious software
o 悪意のあるソフトウェアへのトークン発行
o unintended issuance of powerful tokens with resource owner credentials flow
o リソース所有者の資格情報フローを使用した強力なトークンの意図しない発行
Tokens should generally expire after a reasonable duration. This complements and strengthens other security measures (such as signatures) and reduces the impact of all kinds of token leaks. Depending on the risk associated with token leakage, tokens may expire after a few minutes (e.g., for payment transactions) or stay valid for hours (e.g., read access to contacts).
トークンは通常、妥当な期間が経過すると期限切れになります。これにより、他のセキュリティ対策（署名など）が補完および強化され、あらゆる種類のトークンリークの影響が軽減されます。トークンの漏洩に関連するリスクに応じて、トークンは数分後に（たとえば、支払い取引の場合）有効期限が切れるか、数時間有効なままになる（たとえば、連絡先への読み取りアクセス）可能性があります。
The expiration time is determined by several factors, including:
有効期限は、次のようないくつかの要因によって決定されます。
o risk associated with token leakage,
o トークンの漏洩に伴うリスク
o duration of the underlying access grant,
o 根本的なアクセス許可の期間、
o duration until the modification of an access grant should take effect, and
o アクセス許可の変更が有効になるまでの期間、および
o time required for an attacker to guess or produce a valid token.
o 攻撃者が有効なトークンを推測または生成するのに必要な時間。
A short expiration time for tokens is a means of protection against the following threats:
トークンの短い有効期限は、次の脅威に対する保護の手段です。
o replay
o リプレイ
o token leak (a short expiration time will reduce impact)
o トークンリーク（有効期限が短いと影響が少なくなります）
o online guessing (a short expiration time will reduce the likelihood of success)
o オンライン推測（有効期限が短いと、成功する可能性が低くなります）
Note: Short token duration requires more precise clock synchronization between the authorization server and resource server. Furthermore, shorter duration may require more token refreshes (access token) or repeated end-user authorization processes (authorization "code" and refresh token).
注：トークンの持続時間が短い場合は、許可サーバーとリソースサーバー間のより正確なクロック同期が必要です。さらに、期間が短いほど、より多くのトークンの更新（アクセストークン）または繰り返されるエンドユーザー承認プロセス（承認 "コード"および更新トークン）が必要になる場合があります。
The authorization server may restrict the number of requests or operations that can be performed with a certain token. This mechanism can be used to mitigate the following threats:
許可サーバーは、特定のトークンで実行できる要求または操作の数を制限する場合があります。このメカニズムは、次の脅威を軽減するために使用できます。
o replay of tokens
o トークンの再生
o guessing
o 推測
For example, if an authorization server observes more than one attempt to redeem an authorization "code", the authorization server may want to revoke all access tokens granted based on the authorization "code" as well as reject the current request.
たとえば、承認サーバーが承認「コード」を引き換えようとする複数の試みを観察した場合、承認サーバーは、承認「コード」に基づいて付与されたすべてのアクセストークンを取り消し、現在のリクエストを拒否する場合があります。
As with the authorization "code", access tokens may also have a limited number of operations. This either forces client applications to re-authenticate and use a refresh token to obtain a fresh access token, or forces the client to re-authorize the access token by involving the user.
認可「コード」と同様に、アクセストークンにも限られた数の操作があります。これにより、クライアントアプリケーションは再認証され、更新トークンを使用して新しいアクセストークンを取得するか、クライアントにユーザーを関与させてアクセストークンを再承認させます。
Authorization servers in multi-service environments may consider issuing tokens with different content to different resource servers and to explicitly indicate in the token the target server to which a token is intended to be sent. SAML assertions (see [OASIS.saml-core-2.0-os]) use the Audience element for this purpose. This countermeasure can be used in the following situations:
マルチサービス環境の承認サーバーは、異なるコンテンツを持つトークンを異なるリソースサーバーに発行することを検討し、トークンの送信先のターゲットサーバーをトークンで明示的に示すことができます。 SAMLアサーション（[OASIS.saml-core-2.0-os]を参照）は、この目的でAudience要素を使用します。この対策は、次の状況で使用できます。
o It reduces the impact of a successful replay attempt, since the token is applicable to a single resource server only.
o トークンは単一のリソースサーバーにのみ適用できるため、成功した再生試行の影響が軽減されます。
o It prevents abuse of a token by a rogue resource server or client, since the token can only be used on that server. It is rejected by other servers.
o トークンはそのサーバーでのみ使用できるため、不正なリソースサーバーまたはクライアントによるトークンの悪用を防ぎます。他のサーバーによって拒否されました。
o It reduces the impact of leakage of a valid token to a counterfeit resource server.
o 有効なトークンが偽造リソースサーバーに漏洩する影響を軽減します。
This may be used to indicate to a resource server which endpoint URL has been used to obtain the token. This measure will allow the detection of requests from a counterfeit resource server, since such a token will contain the endpoint URL of that server.
これは、トークンの取得に使用されたエンドポイントURLをリソースサーバーに示すために使用できます。そのようなトークンにはそのサーバーのエンドポイントURLが含まれているため、この手段により、偽造リソースサーバーからの要求を検出できます。
Deployments may consider only using tokens with explicitly defined scopes, where every scope is associated with a particular resource server. This approach can be used to mitigate attacks where a resource server or client uses a token for a different purpose than the one intended.
デプロイメントでは、スコープが明示的に定義されたトークンのみを使用することを検討できます。スコープはすべて、特定のリソースサーバーに関連付けられています。このアプローチは、リソースサーバーまたはクライアントが意図したものとは異なる目的でトークンを使用する攻撃を緩和するために使用できます。
An authorization server may bind a token to a certain client identifier. This identifier should be validated for every request with that token. This technique can be used to
認可サーバーは、トークンを特定のクライアント識別子にバインドできます。この識別子は、そのトークンを使用するすべてのリクエストに対して検証する必要があります。この手法は、
o detect token leakage and
o トークンの漏洩を検出し、
o prevent token abuse.
o トークンの乱用を防ぎます。
Note: Validating the client identifier may require the target server to authenticate the client's identifier. This authentication can be based on secrets managed independently of the token (e.g., pre-registered client id/secret on authorization server) or sent with the token itself (e.g., as part of the encrypted token content).
注：クライアント識別子を検証するには、ターゲットサーバーがクライアントの識別子を認証する必要があります。この認証は、トークンとは別に管理されたシークレット（承認サーバーで事前に登録されたクライアントID /シークレットなど）に基づくことも、トークン自体（たとえば、暗号化されたトークンコンテンツの一部として）とともに送信することもできます。
Self-contained tokens should be signed in order to detect any attempt to modify or produce faked tokens (e.g., Hash-based Message Authentication Code or digital signatures).
自己完結型トークンは、偽造トークンを変更または生成する試みを検出するために署名する必要があります（ハッシュベースのメッセージ認証コードまたはデジタル署名など）。
Self-contained tokens may be encrypted for confidentiality reasons or to protect system internal data. Depending on token format, keys (e.g., symmetric keys) may have to be distributed between server nodes. The method of distribution should be defined by the token and the encryption used.
自己完結型のトークンは、機密保持の理由またはシステムの内部データを保護するために暗号化される場合があります。トークンの形式によっては、キー（対称キーなど）をサーバーノード間で配布する必要があります。配布方法は、使用するトークンと暗号化によって定義する必要があります。
For service providers intending to implement an assertion-based token design, it is highly recommended to adopt a standard assertion format (such as SAML [OASIS.saml-core-2.0-os] or the JavaScript Object Notation Web Token (JWT) [OAuth-JWT]).
アサーションベースのトークン設計を実装するサービスプロバイダーの場合、標準のアサーションフォーマット（SAML [OASIS.saml-core-2.0-os]またはJavaScript Object Notation Web Token（JWT）[OAuthなど）を採用することを強くお勧めします。 -JWT]）。
The following measures should be used to protect access tokens:
アクセストークンを保護するには、次の方法を使用する必要があります。
o Keep them in transient memory (accessible by the client application only).
o それらを一時メモリに保持します（クライアントアプリケーションからのみアクセス可能）。
o Pass tokens securely using secure transport (TLS).
o セキュアなトランスポート（TLS）を使用してトークンを安全に渡します。
o Ensure that client applications do not share tokens with 3rd parties.
o クライアントアプリケーションがサードパーティとトークンを共有しないようにします。
This section describes considerations related to the OAuth authorization server endpoint.
このセクションでは、OAuth承認サーバーエンドポイントに関連する考慮事項について説明します。
If an authorization server observes multiple attempts to redeem an authorization grant (e.g., such as an authorization "code"), the authorization server may want to revoke all tokens granted based on the authorization grant.
許可サーバーが許可付与を引き換える複数の試み（例えば、許可「コード」など）を観察する場合、許可サーバーは、許可付与に基づいて許可されたすべてのトークンを取り消すことを望む場合があります。
The authorization server may decide, based on an appropriate policy, not to issue refresh tokens. Since refresh tokens are long-term credentials, they may be subject to theft. For example, if the authorization server does not trust a client to securely store such tokens, it may refuse to issue such a client a refresh token.
承認サーバーは、適切なポリシーに基づいて、更新トークンを発行しないことを決定する場合があります。更新トークンは長期的な認証情報であるため、盗難に遭う可能性があります。たとえば、認証サーバーがクライアントを信頼してこのようなトークンを安全に格納しない場合、そのようなクライアントに更新トークンを発行することを拒否することがあります。
The authorization server should match every refresh token to the identifier of the client to whom it was issued. The authorization server should check that the same "client_id" is present for every request to refresh the access token. If possible (e.g., confidential clients), the authorization server should authenticate the respective client.
承認サーバーは、すべての更新トークンを、それが発行されたクライアントの識別子と照合する必要があります。許可サーバーは、アクセストークンを更新するすべての要求に同じ「client_id」が存在することを確認する必要があります。可能であれば（機密クライアントなど）、承認サーバーはそれぞれのクライアントを認証する必要があります。
This is a countermeasure against refresh token theft or leakage.
リフレッシュトークンの盗難、漏洩対策です。
Note: This binding should be protected from unauthorized modifications.
注：このバインディングは、無許可の変更から保護する必要があります。
Refresh token rotation is intended to automatically detect and prevent attempts to use the same refresh token in parallel from different apps/devices. This happens if a token gets stolen from the client and is subsequently used by both the attacker and the legitimate client. The basic idea is to change the refresh token value with every refresh request in order to detect attempts to obtain access tokens using old refresh tokens. Since the authorization server cannot determine whether the attacker or the legitimate client is trying to access, in case of such an access attempt the valid refresh token and the access authorization associated with it are both revoked.
更新トークンのローテーションは、異なるアプリ/デバイスから同じ更新トークンを並行して使用する試みを自動的に検出して防止することを目的としています。これは、トークンがクライアントから盗まれ、その後攻撃者と正当なクライアントの両方で使用された場合に発生します。基本的な考え方は、古いリフレッシュトークンを使用してアクセストークンを取得する試みを検出するために、リフレッシュリクエストごとにリフレッシュトークンの値を変更することです。承認サーバーは攻撃者と正当なクライアントのどちらがアクセスを試みているかを判断できないため、そのようなアクセスが試みられた場合、有効な更新トークンとそれに関連付けられているアクセス許可の両方が取り消されます。
The OAuth specification supports this measure in that the token's response allows the authorization server to return a new refresh token even for requests with grant type "refresh_token".
OAuth仕様は、トークンの応答で許可サーバーが許可タイプ "refresh_token"のリクエストでも新しいリフレッシュトークンを返すことができるという点で、この測定をサポートしています。
Note: This measure may cause problems in clustered environments, since usage of the currently valid refresh token must be ensured. In such an environment, other measures might be more appropriate.
注：現在有効な更新トークンを確実に使用する必要があるため、クラスター化された環境では、この対策により問題が発生する可能性があります。このような環境では、他の対策の方が適切な場合があります。
The authorization server may allow clients or end users to explicitly request the invalidation of refresh tokens. A mechanism to revoke tokens is specified in [OAuth-REVOCATION].
承認サーバーでは、クライアントまたはエンドユーザーが更新トークンの無効化を明示的に要求できるようにする場合があります。トークンを取り消すメカニズムは、[OAuth-REVOCATION]で指定されています。
This is a countermeasure against:
これは次の対策です。
o device theft,
o デバイスの盗難、
o impersonation of a resource owner, or
o リソース所有者の偽装、または
o suspected compromised client applications.
o 侵害された疑いのあるクライアントアプリケーション。
The authorization server may require the binding of authentication credentials to a device identifier. The International Mobile Station Equipment Identity [IMEI] is one example of such an identifier; there are also operating system-specific identifiers. The authorization server could include such an identifier when authenticating user credentials in order to detect token theft from a particular device.
承認サーバーでは、認証資格情報をデバイス識別子にバインドする必要があります。 International Mobile Station Equipment Identity [IMEI]は、このような識別子の一例です。オペレーティングシステム固有の識別子もあります。認可サーバーは、特定のデバイスからのトークンの盗難を検出するためにユーザーの資格情報を認証するときに、このような識別子を含めることができます。
Note: Any implementation should consider potential privacy implications of using device identifiers.
注：実装では、デバイス識別子の使用によるプライバシーへの影響を考慮する必要があります。
For newer browsers, avoidance of iFrames can be enforced on the server side by using the X-FRAME-OPTIONS header (see [X-Frame-Options]). This header can have two values, "DENY" and "SAMEORIGIN", which will block any framing or any framing by sites with a different origin, respectively. The value "ALLOW-FROM" specifies a list of trusted origins that iFrames may originate from.
新しいブラウザーでは、X-FRAME-OPTIONSヘッダーを使用してサーバー側でiFrameの回避を強制できます（[X-Frame-Options]を参照）。このヘッダーには、「DENY」と「SAMEORIGIN」の2つの値を含めることができます。これにより、フレーミングまたは送信元が異なるサイトによるフレーミングがそれぞれブロックされます。値「ALLOW-FROM」は、iFrameの発信元である信頼できる発信元のリストを指定します。
This is a countermeasure against the following threat:
これは、次の脅威への対策です。
o Clickjacking attacks
o クリックジャッキング攻撃
As described in Section 3 (Security Features), clients are identified, authenticated, and authorized for several purposes, such as to:
セクション3（セキュリティ機能）で説明されているように、クライアントは次のようないくつかの目的で識別、認証、および承認されます。
o Collate requests to the same client,
o 同じクライアントへの要求を照合し、
o Indicate to the user that the client is recognized by the authorization server,
o クライアントが許可サーバーによって認識されることをユーザーに示します。
o Authorize access of clients to certain features on the authorization server or resource server, and
o 承認サーバーまたはリソースサーバー上の特定の機能へのクライアントのアクセスを承認します。
o Log a client identifier to log files for analysis or statistics.
o クライアント識別子をログに記録して、分析または統計のためにファイルをログに記録します。
Due to the different capabilities and characteristics of the different client types, there are different ways to support these objectives, which will be described in this section. Authorization server providers should be aware of the security policy and deployment of a particular client and adapt its treatment accordingly. For example, one approach could be to treat all clients as less trustworthy and unsecure. On the other extreme, a service provider could activate every client installation individually by an administrator and in that way gain confidence in the identity of the software package and the security of the environment in which the client is installed. There are several approaches in between.
クライアントの種類によって機能や特性が異なるため、これらの目的をサポートする方法はいくつかあります。このセクションで説明します。承認サーバープロバイダーは、セキュリティポリシーと特定のクライアントの展開を認識し、それに応じてその処理を調整する必要があります。たとえば、1つのアプローチは、すべてのクライアントを信頼性が低く安全でないものとして扱うことです。反対に、サービスプロバイダーは管理者がすべてのクライアントインストールを個別にアクティブ化し、その方法でソフトウェアパッケージのIDとクライアントがインストールされている環境のセキュリティに信頼を得ることができます。中間にはいくつかのアプローチがあります。
5.2.3.1. Don't Issue Secrets to Clients with Inappropriate Security Policy
5.2.3.1. 不適切なセキュリティポリシーを使用してクライアントにシークレットを発行しない
Authorization servers should not issue secrets to clients that cannot protect secrets ("public" clients). This reduces the probability of the server treating the client as strongly authenticated.
承認サーバーは、シークレットを保護できないクライアント（「パブリック」クライアント）にシークレットを発行するべきではありません。これにより、サーバーがクライアントを強力に認証されたものとして扱う可能性が低くなります。
For example, it is of limited benefit to create a single client id and secret that are shared by all installations of a native application. Such a scenario requires that this secret must be transmitted from the developer via the respective distribution channel, e.g., an application market, to all installations of the application on end-user devices. A secret, burned into the source code of the application or an associated resource bundle, is not protected from reverse engineering. Secondly, such secrets cannot be revoked, since this would immediately put all installations out of work. Moreover, since the authorization server cannot really trust the client's identifier, it would be dangerous to indicate to end users the trustworthiness of the client.
たとえば、ネイティブアプリケーションのすべてのインストールで共有される単一のクライアントIDとシークレットを作成することの利点は限られています。このようなシナリオでは、この秘密を開発者から、それぞれの配布チャネル、たとえばアプリケーション市場を介して、エンドユーザーデバイス上のアプリケーションのすべてのインストールに送信する必要があります。アプリケーションまたは関連するリソースバンドルのソースコードに焼き付けられた秘密は、リバースエンジニアリングから保護されません。次に、このような秘密を取り消すことはできません。これにより、すべてのインストールがすぐに機能しなくなるためです。さらに、認可サーバーはクライアントの識別子を実際には信頼できないため、エンドユーザーにクライアントの信頼性を示すことは危険です。
There are other ways to achieve a reasonable security level, as described in the following sections.
次のセクションで説明するように、妥当なセキュリティレベルを実現する方法は他にもあります。
Authorization servers should not allow automatic authorization for public clients. The authorization server may issue an individual client id but should require that all authorizations are approved by the end user. For clients without secrets, this is a countermeasure against the following threat:
承認サーバーでは、パブリッククライアントの自動承認を許可しないでください。承認サーバーは個々のクライアントIDを発行できますが、すべての承認がエンドユーザーによって承認される必要があります。シークレットのないクライアントの場合、これは次の脅威への対策です。
o Impersonation of public client applications.
o パブリッククライアントアプリケーションの偽装。
The authorization server may issue a "client_id" and bind the "client_id" to a certain pre-configured "redirect_uri". Any authorization request with another redirect URI is refused automatically. Alternatively, the authorization server should not accept any dynamic redirect URI for such a "client_id" and instead should always redirect to the well-known pre-configured redirect URI. This is a countermeasure for clients without secrets against the following threats:
認可サーバーは「client_id」を発行し、「client_id」を特定の事前設定された「redirect_uri」にバインドできます。別のリダイレクトURIを使用した承認リクエストは自動的に拒否されます。あるいは、許可サーバーは、そのような「client_id」の動的リダイレクトURIを受け入れず、代わりに、よく知られた事前構成されたリダイレクトURIに常にリダイレクトする必要があります。これは、次の脅威に対する秘密のないクライアントに対する対策です。
o Cross-site scripting attacks
o クロスサイトスクリプティング攻撃
o Impersonation of public client applications
o パブリッククライアントアプリケーションの偽装
An authorization server may issue separate client identifiers and corresponding secrets to the different installations of a particular client (i.e., software package). The effect of such an approach would be to turn otherwise "public" clients back into "confidential" clients.
承認サーバーは、特定のクライアント（つまり、ソフトウェアパッケージ）の異なるインストールに対して、個別のクライアント識別子と対応するシークレットを発行する場合があります。そのようなアプローチの効果は、そうでなければ「パブリック」クライアントを「機密」クライアントに戻すことです。
For web applications, this could mean creating one "client_id" and "client_secret" for each web site on which a software package is installed. So, the provider of that particular site could request a client id and secret from the authorization server during the setup of the web site. This would also allow the validation of some of the properties of that web site, such as redirect URI, web site URL, and whatever else proves useful. The web site provider has to ensure the security of the client secret on the site.
Webアプリケーションの場合、これは、ソフトウェアパッケージがインストールされているWebサイトごとに1つの「client_id」と「client_secret」を作成することを意味します。そのため、その特定のサイトのプロバイダーは、Webサイトのセットアップ中に認証サーバーにクライアントIDとシークレットを要求できます。これにより、リダイレクトURI、WebサイトのURLなど、そのWebサイトのいくつかのプロパティの検証や、その他の有用な検証も可能になります。 Webサイトプロバイダーは、サイト上のクライアントシークレットのセキュリティを確保する必要があります。
For native applications, things are more complicated because every copy of a particular application on any device is a different installation. Installation-specific secrets in this scenario will require obtaining a "client_id" and "client_secret" either
ネイティブアプリケーションの場合、デバイス上の特定のアプリケーションのすべてのコピーが異なるインストールであるため、状況はさらに複雑になります。このシナリオのインストール固有のシークレットでは、「client_id」と「client_secret」のいずれかを取得する必要があります
1. during the download process from the application market, or
1. アプリケーション市場からのダウンロードプロセス中、または
2. during installation on the device.
2. デバイスへのインストール中。
Either approach will require an automated mechanism for issuing client ids and secrets, which is currently not defined by OAuth.
どちらのアプローチでも、クライアントIDとシークレットを発行するための自動化メカニズムが必要になりますが、これは現在OAuthで定義されていません。
The first approach would allow the achievement of a certain level of trust in the authenticity of the application, whereas the second option only allows the authentication of the installation but not the validation of properties of the client. But this would at least help to prevent several replay attacks. Moreover, installation-specific "client_ids" and secrets allow the selective revocation of all refresh tokens of a specific installation at once.
最初の方法では、アプリケーションの信頼性を一定のレベルで信頼できるようになりますが、2番目の方法では、インストールの認証のみが可能で、クライアントのプロパティの検証はできません。しかし、これは少なくともいくつかのリプレイ攻撃を防ぐのに役立ちます。さらに、インストール固有の「client_ids」とシークレットを使用すると、特定のインストールのすべての更新トークンを一度に選択的に取り消すことができます。
An authorization server should require all clients to register their "redirect_uri", and the "redirect_uri" should be the full URI as defined in [RFC6749]. The way that this registration is performed is out of scope of this document. As per the core spec, every actual redirect URI sent with the respective "client_id" to the end-user authorization endpoint must match the registered redirect URI. Where it does not match, the authorization server should assume that the inbound GET request has been sent by an attacker and refuse it. Note: The authorization server should not redirect the user agent back to the redirect URI of such an authorization request. Validating the pre-registered "redirect_uri" is a countermeasure against the following threats:
認可サーバーは、すべてのクライアントに「redirect_uri」の登録を要求する必要があり、「redirect_uri」は、[RFC6749]で定義されている完全なURIにする必要があります。この登録の実行方法は、このドキュメントの範囲外です。コア仕様に従って、それぞれの「client_id」とともにエンドユーザー認証エンドポイントに送信される実際のすべてのリダイレクトURIは、登録されているリダイレクトURIと一致する必要があります。一致しない場合、承認サーバーは、インバウンドGETリクエストが攻撃者によって送信されたと想定し、それを拒否する必要があります。注：許可サーバーは、ユーザーエージェントをそのような許可要求のリダイレクトURIにリダイレクトしないでください。事前登録された「redirect_uri」の検証は、次の脅威への対策です。
o Authorization "code" leakage through counterfeit web site: allows authorization servers to detect attack attempts after the first redirect to an end-user authorization endpoint (Section 4.4.1.7).
o 偽造Webサイトを介した認証「コード」の漏えい：エンドユーザーの認証エンドポイントに最初にリダイレクトした後、認証サーバーが攻撃の試みを検出できるようにします（セクション4.4.1.7）。
o Open redirector attack via a client redirection endpoint (Section 4.1.5).
o クライアントリダイレクトエンドポイントを介したオープンリダイレクト攻撃（セクション4.1.5）。
o Open redirector phishing attack via an authorization server redirection endpoint (Section 4.2.4).
o 承認サーバーのリダイレクトエンドポイントを介したリダイレクターフィッシング攻撃を開きます（セクション4.2.4）。
The underlying assumption of this measure is that an attacker will need to use another redirect URI in order to get access to the authorization "code". Deployments might consider the possibility of an attacker using spoofing attacks to a victim's device to circumvent this security measure.
この対策の根本的な前提は、攻撃者が承認「コード」にアクセスするために別のリダイレクトURIを使用する必要があることです。配備では、攻撃者が被害者のデバイスにスプーフィング攻撃を使用してこのセキュリティ対策を回避する可能性を検討する場合があります。
Note: Pre-registering clients might not scale in some deployments (manual process) or require dynamic client registration (not specified yet). With the lack of dynamic client registration, a pre-registered "redirect_uri" only works for clients bound to certain deployments at development/configuration time. As soon as dynamic resource server discovery is required, the pre-registered "redirect_uri" may no longer be feasible.
注：クライアントの事前登録は、一部のデプロイメント（手動プロセス）ではスケーリングされないか、動的クライアント登録（まだ指定されていない）を必要とする場合があります。動的クライアント登録がないため、事前登録された「redirect_uri」は、開発/構成時に特定のデプロイメントにバインドされたクライアントに対してのみ機能します。動的リソースサーバーの検出が必要になるとすぐに、事前登録された「redirect_uri」は実行できなくなる可能性があります。
An authorization server may revoke a client's secret in order to prevent abuse of a revealed secret.
認可サーバーは、明らかにされた秘密の悪用を防ぐために、クライアントの秘密を取り消す場合があります。
Note: This measure will immediately invalidate any authorization "code" or refresh token issued to the respective client. This might unintentionally impact client identifiers and secrets used across multiple deployments of a particular native or web application.
注：この方法では、それぞれのクライアントに発行された認証「コード」または更新トークンが直ちに無効になります。これは、特定のネイティブまたはWebアプリケーションの複数のデプロイメントで使用されるクライアント識別子とシークレットに意図せず影響を与える可能性があります。
This a countermeasure against:
これは次の対策です。
o Abuse of revealed client secrets for private clients
o プライベートクライアントのクライアントシークレットの悪用
5.2.3.7. Use Strong Client Authentication (e.g., client_assertion/ client_token)
5.2.3.7. 強力なクライアント認証を使用する（client_assertion / client_tokenなど）
By using an alternative form of authentication such as client assertion [OAuth-ASSERTIONS], the need to distribute a "client_secret" is eliminated. This may require the use of a secure private key store or other supplemental authentication system as specified by the client assertion issuer in its authentication process.
クライアントアサーション[OAuth-ASSERTIONS]などの認証の代替形式を使用することにより、「client_secret」を配布する必要がなくなります。これには、認証プロセスでクライアントアサーション発行者によって指定された、安全な秘密キーストアまたはその他の補足認証システムの使用が必要になる場合があります。
This section includes considerations for authorization flows involving the end user.
このセクションには、エンドユーザーに関連する承認フローに関する考慮事項が含まれています。
5.2.4.1. Automatic Processing of Repeated Authorizations Requires Client Validation
5.2.4.1. 繰り返される承認の自動処理にはクライアントの検証が必要
Authorization servers should NOT automatically process repeat authorizations where the client is not authenticated through a client secret or some other authentication mechanism such as a signed authentication assertion certificate (Section 5.2.3.7) or validation of a pre-registered redirect URI (Section 5.2.3.5).
承認サーバーは、クライアントがクライアントシークレットまたは署名済み認証アサーション証明書（セクション5.2.3.7）または事前登録されたリダイレクトURIの検証（セクション5.2.3.5）などの他の認証メカニズムによって認証されない場合、繰り返し承認を自動的に処理しないでください。 ）。
The authorization server should clearly explain to the end user what happens in the authorization process and what the consequences are. For example, the user should understand what access he is about to grant to which client for what duration. It should also be obvious to the user whether the server is able to reliably certify certain client properties (web site URL, security policy).
承認サーバーは、承認プロセスで何が発生し、どのような結果になるかをエンドユーザーに明確に説明する必要があります。たとえば、ユーザーは、どのクライアントにどの期間アクセス権を付与しようとしているのかを理解する必要があります。サーバーが特定のクライアントプロパティ（WebサイトのURL、セキュリティポリシー）を確実に認証できるかどうかも、ユーザーには明らかです。
In the authorization process, the user is typically asked to approve a client's request for authorization. This is an important security mechanism by itself because the end user can be involved in the validation of client properties, such as whether the client name known to the authorization server fits the name of the web site or the application the end user is using. This measure is especially helpful in situations where the authorization server is unable to authenticate the client. It is a countermeasure against:
認可プロセスでは、ユーザーは通常、クライアントの認可リクエストを承認するよう求められます。これはそれ自体が重要なセキュリティメカニズムです。これは、承認サーバーに認識されているクライアント名が、エンドユーザーが使用しているWebサイトまたはアプリケーションの名前と一致するかどうかなど、クライアントプロパティの検証にエンドユーザーが関与できるためです。この方法は、許可サーバーがクライアントを認証できない場合に特に役立ちます。これは次の対策です。
o A malicious application
o 悪意のあるアプリケーション
o A client application masquerading as another client
o 別のクライアントを装ったクライアントアプリケーション
The authorization server should bind every authorization "code" to the id of the respective client that initiated the end-user authorization process. This measure is a countermeasure against:
承認サーバーは、すべての承認「コード」を、エンドユーザーの承認プロセスを開始したそれぞれのクライアントのIDにバインドする必要があります。この対策は、以下に対する対策です。
o Replay of authorization "codes" with different client credentials, since an attacker cannot use another "client_id" to exchange an authorization "code" into a token
o 攻撃者は別の「client_id」を使用して認証「コード」をトークンに交換できないため、異なるクライアント認証情報による認証「コード」の再生
o Online guessing of authorization "codes"
o 承認「コード」のオンライン推測
Note: This binding should be protected from unauthorized modifications (e.g., using protected memory and/or a secure database).
注：このバインディングは、不正な変更から保護する必要があります（保護されたメモリや安全なデータベースを使用するなど）。
The authorization server should be able to bind every authorization "code" to the actual redirect URI used as the redirect target of the client in the end-user authorization process. This binding should be validated when the client attempts to exchange the respective authorization "code" for an access token. This measure is a countermeasure against authorization "code" leakage through counterfeit web sites, since an attacker cannot use another redirect URI to exchange an authorization "code" into a token.
承認サーバーは、すべての承認「コード」を、エンドユーザーの承認プロセスでクライアントのリダイレクトターゲットとして使用される実際のリダイレクトURIにバインドできる必要があります。このバインディングは、クライアントがアクセストークンのそれぞれの認証「コード」を交換しようとするときに検証する必要があります。攻撃者は別のリダイレクトURIを使用して承認「コード」をトークンに交換できないため、この対策は、偽のWebサイトを介した承認「コード」の漏洩に対する対策です。
This section deals with considerations for client applications.
このセクションでは、クライアントアプリケーションの考慮事項について説明します。
5.3.1. Don't Store Credentials in Code or Resources Bundled with Software Packages
5.3.1. ソフトウェアパッケージにバンドルされているコードまたはリソースに資格情報を保存しない
Because of the number of copies of client software, there is limited benefit in creating a single client id and secret that is shared by all installations of an application. Such an application by itself would be considered a "public" client, as it cannot be presumed to be able to keep client secrets. A secret, burned into the source code of the application or an associated resource bundle, cannot be protected from reverse engineering. Secondly, such secrets cannot be revoked, since this would immediately put all installations out of work. Moreover, since the authorization server cannot really trust the client's identifier, it would be dangerous to indicate to end users the trustworthiness of the client.
クライアントソフトウェアのコピー数が多いため、アプリケーションのすべてのインストールで共有される単一のクライアントIDとシークレットを作成するメリットは限られています。このようなアプリケーション自体は、クライアントの秘密を保持できるとは想定できないため、「パブリック」クライアントと見なされます。アプリケーションまたは関連するリソースバンドルのソースコードに焼き付けられた秘密は、リバースエンジニアリングから保護できません。次に、このような秘密を取り消すことはできません。これにより、すべてのインストールがすぐに機能しなくなるためです。さらに、認可サーバーはクライアントの識別子を実際には信頼できないため、エンドユーザーにクライアントの信頼性を示すことは危険です。
5.3.2. Use Standard Web Server Protection Measures (for Config Files and Databases)
5.3.2. 標準のWebサーバー保護手段を使用する（構成ファイルとデータベースの場合）
Use standard web server protection and configuration measures to protect the integrity of the server, databases, configuration files, and other operational components of the server.
サーバー、データベース、構成ファイル、およびサーバーの他の運用コンポーネントの整合性を保護するために、標準のWebサーバー保護および構成手段を使用します。
There are different ways to store secrets of all kinds (tokens, client secrets) securely on a device or server.
すべての種類のシークレット（トークン、クライアントシークレット）をデバイスまたはサーバーに安全に保存するには、さまざまな方法があります。
Most multi-user operating systems segregate the personal storage of different system users. Moreover, most modern smartphone operating systems even support the storage of application-specific data in separate areas of file systems and protect the data from access by other applications. Additionally, applications can implement confidential data by using a user-supplied secret, such as a PIN or password.
ほとんどのマルチユーザーオペレーティングシステムは、さまざまなシステムユーザーの個人用ストレージを分離します。さらに、最新のスマートフォンオペレーティングシステムのほとんどは、アプリケーション固有のデータをファイルシステムの別の領域に保存することをサポートし、他のアプリケーションによるアクセスからデータを保護します。さらに、アプリケーションは、PINやパスワードなどのユーザー指定のシークレットを使用して機密データを実装できます。
Another option is to swap refresh token storage to a trusted backend server. This option in turn requires a resilient authentication mechanism between the client and backend server. Note: Applications should ensure that confidential data is kept confidential even after reading from secure storage, which typically means keeping this data in the local memory of the application.
別のオプションは、更新トークンストレージを信頼できるバックエンドサーバーにスワップすることです。このオプションでは、クライアントとバックエンドサーバー間の回復力のある認証メカニズムが必要になります。注：アプリケーションは、安全なストレージから読み取った後でも機密データが確実に機密に保たれるようにする必要があります。これは、通常、このデータをアプリケーションのローカルメモリに保持することを意味します。
On a typical modern phone, there are many "device lock" options that can be utilized to provide additional protection when a device is stolen or misplaced. These include PINs, passwords, and other biometric features such as "face recognition". These are not equal in the level of security they provide.
典型的な現代の電話では、デバイスが盗まれたり置き忘れられたりしたときに追加の保護を提供するために利用できる多くの「デバイスロック」オプションがあります。これらには、PIN、パスワード、および「顔認識」などの他の生体認証機能が含まれます。これらは、提供するセキュリティのレベルが同じではありません。
The "state" parameter is used to link client requests and prevent CSRF attacks, for example, attacks against the redirect URI. An attacker could inject their own authorization "code" or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).
「状態」パラメーターは、クライアント要求をリンクし、CSRF攻撃（リダイレクトURIに対する攻撃など）を防ぐために使用されます。攻撃者は独自の認証「コード」またはアクセストークンを挿入する可能性があります。これにより、クライアントは被害者ではなく、攻撃者の保護されたリソースに関連付けられたアクセストークンを使用する可能性があります（被害者の銀行口座情報を、アタッカー）。
The client should utilize the "state" request parameter to send the authorization server a value that binds the request to the user agent's authenticated state (e.g., a hash of the session cookie used to authenticate the user agent) when making an authorization request. Once authorization has been obtained from the end user, the authorization server redirects the end-user's user agent back to the client with the required binding value contained in the "state" parameter.
クライアントは、「state」リクエストパラメータを使用して、認可リクエストを行うときに、リクエストをユーザーエージェントの認証済みの状態にバインドする値（ユーザーエージェントの認証に使用されるセッションCookieのハッシュなど）を認可サーバーに送信する必要があります。エンドユーザーから認証が取得されると、認証サーバーは、「state」パラメーターに含まれている必要なバインディング値を使用して、エンドユーザーのユーザーエージェントをクライアントにリダイレクトします。
The binding value enables the client to verify the validity of the request by matching the binding value to the user agent's authenticated state.
バインディング値を使用すると、クライアントは、バインディング値をユーザーエージェントの認証済み状態と照合することで、リクエストの有効性を検証できます。
The following section details security considerations for resource servers.
次のセクションでは、リソースサーバーのセキュリティに関する考慮事項について詳しく説明します。
Authorization headers are recognized and specially treated by HTTP proxies and servers. Thus, the usage of such headers for sending access tokens to resource servers reduces the likelihood of leakage or unintended storage of authenticated requests in general, and especially Authorization headers.
承認ヘッダーはHTTPプロキシとサーバーによって認識され、特別に処理されます。したがって、アクセストークンをリソースサーバーに送信するためにこのようなヘッダーを使用すると、認証された要求、特にAuthorizationヘッダーの漏洩や意図しない保存の可能性が低くなります。
An authorization server may bind tokens to a certain client identifier and enable resource servers to validate that association on resource access. This will require the resource server to authenticate the originator of a request as the legitimate owner of a particular token. There are several options to implement this countermeasure:
承認サーバーは、トークンを特定のクライアント識別子にバインドし、リソースサーバーがリソースアクセス時にその関連付けを検証できるようにします。これには、リソースサーバーが要求の発信者を特定のトークンの正当な所有者として認証する必要があります。この対策を実装するには、いくつかのオプションがあります。
o The authorization server may associate the client identifier with the token (either internally or in the payload of a self-contained token). The client then uses client certificate-based HTTP authentication on the resource server's endpoint to authenticate its identity, and the resource server validates the name with the name referenced by the token.
o 承認サーバーは、クライアント識別子をトークンに関連付けることができます（内部または自己完結型トークンのペイロード内）。次に、クライアントはリソースサーバーのエンドポイントでクライアント証明書ベースのHTTP認証を使用してIDを認証し、リソースサーバーはトークンによって参照される名前で名前を検証します。
o Same as the option above, but the client uses his private key to sign the request to the resource server (the public key is either contained in the token or sent along with the request).
o 上記のオプションと同じですが、クライアントはプライベートキーを使用してリソースサーバーへのリクエストに署名します（パブリックキーはトークンに含まれるか、リクエストとともに送信されます）。
o Alternatively, the authorization server may issue a token-bound key, which the client uses in a Holder-of-Key proof to authenticate the client's use of the token. The resource server obtains the secret directly from the authorization server, or the secret is contained in an encrypted section of the token. In that way, the resource server does not "know" the client but is able to validate whether the authorization server issued the token to that client.
o または、承認サーバーはトークンバインドキーを発行することもできます。これは、クライアントがキーホルダーの証明で使用して、クライアントのトークンの使用を認証します。リソースサーバーは認証サーバーから直接シークレットを取得するか、シークレットがトークンの暗号化されたセクションに含まれています。このようにして、リソースサーバーはクライアントを "認識"しませんが、承認サーバーがそのクライアントにトークンを発行したかどうかを検証できます。
Authenticated requests are a countermeasure against abuse of tokens by counterfeit resource servers.
認証された要求は、偽造リソースサーバーによるトークンの悪用に対する対策です。
A resource server may decide to accept signed requests only, either to replace transport-level security measures or to complement such measures. Every signed request should be uniquely identifiable and should not be processed twice by the resource server. This countermeasure helps to mitigate:
リソースサーバーは、トランスポートレベルのセキュリティ対策を置き換えるため、またはそのような対策を補完するために、署名された要求のみを受け入れることを決定できます。署名されたすべての要求は一意に識別可能でなければならず、リソースサーバーによって2回処理されるべきではありません。この対策は、以下を軽減するのに役立ちます。
o modifications of the message and
o メッセージの変更と
o replay attempts
o リプレイ試行
OAuth, as a security protocol, is distinctive in that its flow usually involves significant user interaction, making the end user a part of the security model. This creates some important difficulties in defending against some of the threats discussed above. Some of these points have already been made, but it's worth repeating and highlighting them here.
セキュリティプロトコルとしてのOAuthは、通常、そのフローに重要なユーザーの操作が含まれ、エンドユーザーがセキュリティモデルの一部になるという点で独特です。これにより、上で説明した脅威のいくつかを防御する上でいくつかの重要な困難が生じます。これらのポイントのいくつかはすでに作成されていますが、ここで繰り返し強調表示することは価値があります。
o End users must understand what they are being asked to approve (see Section 5.2.4.2). Users often do not have the expertise to understand the ramifications of saying "yes" to an authorization request and are likely not to be able to see subtle differences in the wording of requests. Malicious software can confuse the user, tricking the user into approving almost anything.
o エンドユーザーは、承認を求められている内容を理解する必要があります（セクション5.2.4.2を参照）。ユーザーは、承認リクエストに対して「はい」と言った場合の影響を理解する専門知識を持たないことが多く、リクエストの表現に微妙な違いを見ることはできないでしょう。悪意のあるソフトウェアはユーザーを混乱させ、ユーザーをだましてほとんどすべてを承認させます。
o End-user devices are prone to software compromise. This has been a long-standing problem, with frequent attacks on web browsers and other parts of the user's system. But with the increasing popularity of user-installed "apps", the threat posed by compromised or malicious end-user software is very strong and is one that is very difficult to mitigate.
o エンドユーザーのデバイスは、ソフトウェアが侵害される傾向があります。これは、Webブラウザーやユーザーのシステムの他の部分への頻繁な攻撃により、長年の問題でした。しかし、ユーザーがインストールした「アプリ」の人気が高まるにつれ、侵害された、または悪意のあるエンドユーザーソフトウェアによってもたらされる脅威は非常に強く、緩和するのが非常に困難になっています。
o Be aware that users will demand to install and run such apps, and that compromised or malicious ones can steal credentials at many points in the data flow. They can intercept the very user login credentials that OAuth is designed to protect. They can request authorization far beyond what they have led the user to understand and approve. They can automate a response on behalf of the user, hiding the whole process. No solution is offered here, because none is known; this remains in the space between better security and better usability.
o ユーザーはそのようなアプリのインストールと実行を要求し、侵害されたアプリや悪意のあるアプリはデータフローの多くのポイントで認証情報を盗む可能性があることに注意してください。 OAuthが保護するように設計されているユーザーログイン資格情報そのものを傍受できます。彼らは、ユーザーが理解して承認するために導いたものをはるかに超えた承認を要求することができます。ユーザーに代わって応答を自動化し、プロセス全体を隠すことができます。何も知られていないため、ここではソリューションは提供されていません。これは、より優れたセキュリティと使いやすさの間の空間に残ります。
o Addressing these issues by restricting the use of user-installed software may be practical in some limited environments and can be used as a countermeasure in those cases. Such restrictions are not practical in the general case, and mechanisms for after-the-fact recovery should be in place.
o ユーザーがインストールしたソフトウェアの使用を制限することでこれらの問題に対処することは、一部の限られた環境では実用的であり、そのような場合の対策として使用できます。このような制限は一般的なケースでは実用的ではなく、事後回復のためのメカニズムを導入する必要があります。
o While end users are mostly incapable of properly vetting applications they load onto their devices, those who deploy authorization servers might have tools at their disposal to mitigate malicious clients. For example, a well-run authorization server must only assert client properties to the end user it is effectively capable of validating, explicitly point out which properties it cannot validate, and indicate to the end user the risk associated with granting access to the particular client.
o エンドユーザーは、デバイスにロードするアプリケーションを適切に検査することはほとんどできませんが、承認サーバーを展開するユーザーは、悪意のあるクライアントを軽減するためのツールを自由に利用できます。たとえば、適切に実行された承認サーバーは、有効に検証できるエンドユーザーに対してのみクライアントプロパティをアサートし、検証できないプロパティを明示的に指摘し、特定のクライアントへのアクセス許可に関連するリスクをエンドユーザーに示す必要があります。 。
We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu, Francisco Corella, Peifung E. Lam, Shane B. Weeden, Skylar Woodward, Niv Steingarten, Tim Bray, and James H. Manger for their comments and contributions.
Stephen Farrell、Barry Leiba、Hui-Lan Lu、Francisco Corella、Peifung E. Lam、Shane B. Weeden、Skylar Woodward、Niv Steingarten、Tim Bray、James H. Mangerのコメントと貢献に感謝します。
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
[RFC6749] Hardt、D。、「The OAuth 2.0 Authorization Framework」、RFC 6749、2012年10月。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6750]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、2012年10月。
[Framebusting] Rydstedt, G., Bursztein, Boneh, D., and C. Jackson, "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0 Security and Privacy Workshop, May 2010, <http://elie.im/ publication/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites>.
[Framebusting] Rydstedt、G.、Bursztein、Boneh、D。、およびC. Jackson、「バスティングフレームバスティング：人気サイトでのクリックジャッキングの脆弱性の研究」、IEEE 3rd Web 2.0セキュリティおよびプライバシーワークショップ、2010年5月、<http： //elie.im/ publication / busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites>。
[IMEI] 3GPP, "International Mobile station Equipment Identities (IMEI)", 3GPP TS 22.016 11.0.0, September 2012, <http://www.3gpp.org/ftp/Specs/html-info/22016.htm>.
[IMEI] 3GPP、「International Mobile Station Equipment Identities（IMEI）」、3GPP TS 22.016 11.0.0、2012年9月、<http://www.3gpp.org/ftp/Specs/html-info/22016.htm>。
[OASIS.saml-core-2.0-os] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/ v2.0/saml-core-2.0-os.pdf>.
[OASIS.saml-core-2.0-os] Cantor、S.、Ed。、Kemp、J.、Ed。、Philpott、R.、Ed。、and E. Maler、Ed。、「OASISのアサーションとプロトコルSecurity Assertion Markup Language（SAML）V2.0 "、OASIS標準saml-core-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/ v2.0 / saml-core- 2.0-os.pdf>。
[OASIS.sstc-saml-bindings-1.1] Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1", September 2003, <http://www.oasis-open.org/committees/download.php/3405/ oasis-sstc-saml-bindings-1.1.pdf>.
[OASIS.sstc-saml-bindings-1.1] Maler、E。、編、Mishra、P。、編、およびR. Philpott、編、「OASISセキュリティアサーションマークアップ言語（SAML）V1のバインディングとプロファイル」 .1、2003年9月、<http://www.oasis-open.org/committees/download.php/3405/ oasis-sstc-saml-bindings-1.1.pdf>。
[OASIS.sstc-sec-analysis-response-01] Linn, J., Ed., and P. Mishra, Ed., "SSTC Response to "Security Analysis of the SAML Single Sign-on Browser/ Artifact Profile"", January 2005, <http://www.oasis-open.org/committees/download.php/ 11191/sstc-gross-sec-analysis-response-01.pdf>.
[OASIS.sstc-sec-analysis-response-01] Linn、J.、Ed。、and P. Mishra、Ed。、 "SSTC Response to" Security Analysis of the SAML Single Sign-on Browser / Artifact Profile ",, 2005年1月、<http://www.oasis-open.org/committees/download.php/ 11191 / sstc-gross-sec-analysis-response-01.pdf>。
[OAuth-ASSERTIONS] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0", Work in Progress, December 2012.
[OAuth-ASSERTIONS]キャンベル、B。、モーティモア、C。、ジョーンズ、M。、およびY.ゴランド、「OAuth 2.0のアサーションフレームワーク」、作業中、2012年12月。
[OAuth-HTTP-MAC] Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed., "OAuth 2.0 Message Authentication Code (MAC) Tokens", Work in Progress, November 2012.
[OAuth-HTTP-MAC] Richer、J。、編、Mills、W。、編、およびH. Tschofenig、編、「OAuth 2.0メッセージ認証コード（MAC）トークン」、Work in Progress、2012年11月。
[OAuth-JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", Work in Progress, December 2012.
[OAuth-JWT] Jones、M.、Bradley、J.、N。崎村、「JSON Web Token（JWT）」、Work in Progress、2012年12月。
[OAuth-REVOCATION] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "Token Revocation", Work in Progress, November 2012.
[OAuth-REVOCATION] Lodderstedt、T.、Ed。、Dronia、S。、およびM. Scurtescu、「Token Revocation」、Work in Progress、2012年11月。
[OPENID] "OpenID Foundation Home Page", <http://openid.net/>.
[OPENID]「OpenID Foundationホームページ」、<http://openid.net/>。
[OWASP] "Open Web Application Security Project Home Page", <https://www.owasp.org/>.
[OWASP]「Open Web Application Security Project Home Page」、<https://www.owasp.org/>。
[Portable-Contacts] Smarr, J., "Portable Contacts 1.0 Draft C", August 2008, <http://portablecontacts.net/>.
[Portable-Contacts] Smarr、J。、「Portable Contacts 1.0 Draft C」、2008年8月、<http://portablecontacts.net/>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[SSL-Latency] Sissel, J., Ed., "SSL handshake latency and HTTPS optimizations", June 2010.
[SSLレイテンシ] Sissel、J。、編、「SSLハンドシェイクレイテンシとHTTPS最適化」、2010年6月。
[Sec-Analysis] Gross, T., "Security Analysis of the SAML Single Sign-on Browser/Artifact Profile", 19th Annual Computer Security Applications Conference, Las Vegas, December 2003.
[Sec-Analysis] Gross、T。、「SAML Single Sign-on Browser / Artifact Profileのセキュリティ分析」、第19回年次コンピュータセキュリティアプリケーション会議、ラスベガス、2003年12月。
[X-Frame-Options] Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options", Work in Progress, October 2012.
[X-Frame-Options] Ross、D。およびT. Gondrom、「HTTPヘッダーX-Frame-Options」、作業中、2012年10月。
[iFrame] World Wide Web Consortium, "Frames in HTML documents", W3C HTML 4.01, December 1999, <http://www.w3.org/TR/html4/present/frames.html#h-16.5>.
[iFrame] World Wide Webコンソーシアム、「HTMLドキュメントのフレーム」、W3C HTML 4.01、1999年12月、<http://www.w3.org/TR/html4/present/frames.html#h-16.5>。
Authors' Addresses
著者のアドレス
Torsten Lodderstedt (editor) Deutsche Telekom AG
Torsten Lodderstedt（編集者）Deutsche Telekom AG
EMail: torsten@lodderstedt.net
Mark McGloin IBM
マーク・マグロインIBM
EMail: mark.mcgloin@ie.ibm.com
Phil Hunt Oracle Corporation
Phil Hunt Oracle Corporation
EMail: phil.hunt@yahoo.com