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
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提供了除OAuth 2.0规范之外的其他安全注意事项。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.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
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
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
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规范之外的其他安全注意事项。它包含以下内容：
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规范的基础，所以它不考虑诸如客户端注册或发现之类的建议扩展，其中许多仍在讨论中。
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 未绑定到特定部署的客户端：例如，支持通过portable contacts 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
o 攻击者可以完全访问客户端和授权服务器以及客户端和资源服务器之间的网络。攻击者可以窃听任何通信
between those parties. He is not assumed to have access to communication between the authorization server and resource server.
在这些党派之间。假定他无权访问授权服务器和资源服务器之间的通信。
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协议的三方中的两方可能串通对第三方发起攻击。例如，客户端和授权服务器可能受到攻击者的控制，并串通欺骗用户以获得对资源的访问。
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节）：“重定向uri”、“客户端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 每个最终用户或其他安全上下文或委派上下文的一个或多个刷新令牌（持久）和访问令牌（暂时）
o trusted certification authority (CA) certificates (HTTPS)
o 受信任的证书颁发机构（CA）证书（HTTPS）
o per-authorization process: "redirect_uri", authorization "code"
o 每个授权过程：“重定向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广泛使用多种令牌（访问令牌、刷新令牌、授权“代码”）。令牌的信息内容可以用两种方式表示，如下所示：
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:
令牌可以通过两种方式调用资源服务器上的请求，如下所示：
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]）。因为仅仅拥有就足以使用令牌，所以端点之间的通信必须安全，以确保只有授权的端点可以捕获令牌。承载令牌对于客户端应用程序来说很方便，因为它不需要他们做任何事情来使用它们（例如身份证明）。承载令牌与浏览器中使用的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客户端或通过非安全通道发送令牌的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:
授权“代码”表示成功的最终用户授权过程的中间结果，并由客户端用于获取访问和刷新令牌。出于两个目的，授权“代码”被发送到客户端的重定向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 referer）、浏览器缓存或日志文件条目将协议参数暴露给潜在的攻击者，并且可以重播。为了减少这一威胁，将传递短期授权“代码”，而不是令牌，并通过客户端和授权服务器之间更安全的直接连接交换令牌。
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.
认证协议通常不考虑代表最终用户的软件组件的身份。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根据其向授权服务器进行身份验证的能力（即维护其客户机凭据的机密性的能力）定义了两种客户机类型，即机密客户机类型和公共客户机类型。机密客户机能够维护客户机凭证的机密性（即，与客户机标识符相关联的客户机机密），或者能够使用其他手段（例如，客户机断言（例如，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.
具有预注册的“重定向uri”且无“客户端机密”的独立于部署的“客户端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.
具有预注册的“重定向uri”和“客户端机密”的独立于部署的“客户端id”仅适用于本机应用程序，因为web应用程序需要不同的重定向uri。不建议使用该类别，因为无法适当保护客户机密（见第4.1.1节）。由于其安全弱点，此类客户机身份与部署无关的客户机具有相同的信任级别，而没有秘密。吊销将影响所有部署。
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.
具有预先注册的“重定向uri”和“客户端机密”的特定于部署的“客户端id”。客户端注册过程确保验证客户端的属性，例如重定向uri、网站URL、网站名称和联系人。这样的客户端标识符可用于上面引用的所有相关用例。对于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.
具有“客户机密钥”且未经验证属性的部署特定“客户机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服务器）或特定设备（本机应用程序）获取。
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 使用强客户端身份验证（例如，客户端断言/客户端令牌），以便攻击者无法获得交换令牌所需的客户端机密（第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.
主机设备（如移动电话）可能被盗。在这种情况下，攻击者可以以合法用户的身份访问所有应用程序。
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 将刷新令牌请求与设备标识相结合（第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）确认、网站机制）。通过使用嵌入式或内部客户机应用程序用户界面，客户机应用程序可以访问其不应访问的其他信息（例如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，该重定向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和类似协议的广泛部署可能会导致用户习惯于被重定向到要求输入密码的网站。如果用户在输入其凭据之前不小心验证这些网站的真实性，攻击者就有可能利用这种做法窃取用户密码。
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 授权服务器应该在基于OAutho开发服务时考虑此类攻击，并且在授权服务器的真实性或请求响应是问题的任何请求中都应该使用传输层安全性（见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注入攻击，从授权服务器的数据库中获取有效的“客户端id”/秘密组合。
Impact: Disclosure of all "client_id"/secret combinations. This allows the attacker to act on behalf of legitimate clients.
影响：泄露所有“客户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.
攻击者可能会尝试猜测有效的“客户端id”/秘密对。
Impact: Disclosure of a single "client_id"/secret pair.
影响：泄露单个“客户端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:
攻击者可能试图窃听授权服务器和客户端之间的授权“代码”传输。此外，授权“代码”通过浏览器传递，这可能会以不同方式无意中将这些代码泄漏给不受信任的网站和攻击者：
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 引用者标题：当网页嵌入内容时，或者当用户从一个网页移动到另一个网页时，浏览器经常传递“引用者”标题。即使源站点不信任目标站点，也可以发送这些引用者标头。referer报头通常记录用于流量分析目的。
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的委派协议造成了特别的风险，因为重定向程序可能会将验证代码泄漏到不受信任的目标站点。
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节；[证券交易委员会分析]；和[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 授权服务器应实施一次性使用限制（见第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.
影响：披露所有授权“代码”，最有可能的还有各自的“重定向uri”和“客户端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 在对最终用户进行身份验证后，授权服务器应请求他/她同意。在这种情况下，授权服务器应该向最终用户解释客户端请求的授权的目的、范围和持续时间。此外，授权服务器应向用户显示其拥有的该客户端的任何身份信息。由用户验证该数据与特定应用程序（如名称）的绑定，并批准授权请求（见第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不是运行用户浏览器的主机的本地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不是运行用户浏览器的主机的本地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.
攻击者滥用现有客户端应用程序，并将其与自己的伪造客户端网站相结合。攻击者依赖于希望客户端应用程序请求访问特定资源服务器的受害者。受害者只看到预期应用程序的正常请求，就批准了该请求。然后，攻击者使用受害者的授权来访问受害者不知不觉授权的信息。
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. 攻击者访问客户端网站（或应用程序）并启动对特定资源服务器的数据访问。客户端网站反过来向资源服务器的授权服务器发起授权请求。攻击者不继续进行授权过程，而是修改由客户端构造的授权服务器最终用户授权URL，以包含一个重定向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. 完成授权过程后，授权服务器将用户代理重定向到攻击者的网站，而不是原始客户端网站。
5. The attacker obtains the authorization "code" from his web site by means that are out of scope of this document.
5. 攻击者通过超出本文档范围的方式从其网站获取授权“代码”。
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和新获得的授权“代码”构造一个指向目标网站（或应用程序）的重定向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 攻击者需要为其授权过程而不是目标网站使用另一个重定向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 id”（参见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的攻击，通过此攻击，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时，用户可能会将其客户端帐户与外部身份提供程序中攻击者的身份相关联。通过这种方式，攻击者可以使用其在外部身份提供商处的凭据从另一台设备登录，从而轻松访问客户机上的受害者数据。
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]）中，该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头（第5.2.2.6节）在服务器端强制执行授权期间避免iFrame。
o For older browsers, JavaScript frame-busting (see [Framebusting]) techniques can be used but may not be effective in all browsers.
o 对于较旧的浏览器，可以使用JavaScript框架分解（请参见[Framebursting]）技术，但并非在所有浏览器中都有效。
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，包括任何nonce等。
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 使用带外发送给资源所有者的一次性机密（例如，通过文本或即时消息）。
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节），该攻击仍然有效。有了这样的防御，攻击者可能需要发出额外的HTTP请求以获取有效的CSRF代码/“state”参数。这显然将攻击的有效性降低了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. 连接清洗：由于客户端是攻击者和授权服务器之间的中继，授权服务器几乎不了解或根本不了解有关攻击者身份的信息。由于很难识别攻击机器，因此对攻击机器的速率限制等防御措施效果较差。尽管攻击者也可以通过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
2. 非对称资源利用：攻击者承担HTTP连接的成本，并导致在授权服务器上建立HTTPS连接；攻击者可以相对轻松地跨多个客户端协调此类HTTPS连接的时间。尽管攻击者可以实现类似的目标，例如，通过在HTTP网页中包含指向授权服务器HTTPS URL的iFrame并引诱web用户访问该网页，但使用此类方案的定时攻击可能更为有效
difficult, as it seems nontrivial to synchronize a large number of users to simultaneously visit a particular site under the attacker's control.
这很困难，因为同步大量用户以同时访问攻击者控制下的特定站点似乎很重要。
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.
攻击者可以尝试使用受害者的身份登录到应用程序或网站。依赖OAuth保护的服务API提供的身份数据登录用户的应用程序容易受到这种威胁。这种模式可以在所谓的“社交登录”场景中找到。
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.
作为一个先决条件，资源服务器提供了一个API来获取关于用户的个人信息，这些信息可以被解释为已经获得了用户身份。从这个意义上讲，客户机将资源服务器API视为“身份”API。客户机利用OAuth获取标识API的访问令牌。然后，它向identity 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
如果客户端使用授权类型“代码”，则攻击者需要从目标客户端应用程序使用的同一身份提供程序收集相应受害者的有效授权“代码”。攻击者诱使受害者使用与目标应用程序相同的身份提供程序登录到恶意应用程序（身份提供程序可能认为该应用程序是合法的）。这将导致身份提供程序的授权服务器发出授权
"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.
各标识API的“代码”。然后，恶意应用程序将此代码发送给攻击者，从而触发目标应用程序内的登录过程。攻击者现在操纵授权响应并用其代码（绑定到其身份）替换受害者的代码。然后，客户机将此代码交换为访问令牌，而identity API则接受该令牌，因为相对于资源服务器，访问群体是正确的。但是，由于identity API返回的标识符由访问令牌中的标识（根据受害者的代码发布）确定，因此攻击者以受害者的身份登录到目标应用程序。
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（cf.[OpenID]）或SAML（cf.[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的一部分直接返回给客户端。假设令牌没有发送到重定向URI目标，因为HTTP用户代理不会将URI的片段部分发送到HTTP服务器。因此，攻击者无法窃听此通信路径上的访问令牌，并且令牌不能通过HTTP Referer头泄漏。
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.
影响：攻击者可以获取用户凭据信息并假定用户的完整身份。
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 引入一次性、每次使用的机密（例如，“客户机机密”）值，这些值在从服务器加载后只能由脚本在小时间窗口中使用。这样做的目的是降低复制客户端脚本以便在攻击者修改的代码中重复使用的有效性。
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时，用户可能会将其客户端帐户与外部身份提供程序中攻击者的身份相关联。通过这种方式，攻击者可以使用其在外部身份提供商处的凭据从另一台设备登录，从而轻松访问客户机上的受害者数据。
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链接起来。这将确保客户端不会被骗完成任何重定向回调，除非它链接到客户端启动的授权请求。“state”参数不应该是可猜测的，客户端应该能够对“state”参数保密。
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.
攻击者可以尝试使用受害者的身份登录到应用程序或网站。依赖OAuth保护的服务API提供的身份数据登录用户的应用程序容易受到这种威胁。这种模式可以在所谓的“社交登录”场景中找到。
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.
作为一个先决条件，资源服务器提供了一个API来获取关于用户的个人信息，这些信息可以被解释为已经获得了用户身份。从这个意义上讲，客户机将资源服务器API视为“身份”API。客户机利用OAuth获取标识API的访问令牌。然后，它向identity 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.
要成功，攻击者需要从目标客户端应用程序使用的同一身份提供程序收集相应受害者的有效访问令牌。攻击者诱使受害者使用与目标应用程序相同的身份提供程序登录到恶意应用程序（身份提供程序可能认为该应用程序是合法的）。这将导致标识提供程序的授权服务器为相应的标识API发出访问令牌。然后，恶意应用程序将此访问令牌发送给攻击者，从而触发目标应用程序内的登录过程。攻击者现在操纵授权响应并将其访问令牌（绑定到其身份）替换为受害者的访问令牌。标识API接受此令牌，因为相对于资源服务器的访问群体是正确的。但由于identity API返回的标识符由访问令牌中的标识确定，因此攻击者以受害者的身份登录到目标应用程序。
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（cf.[OpenID]）或SAML（cf.[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
资源所有者密码凭据授予类型（参见[RFC6749]，第4.3节）通常用于遗留/迁移原因，允许客户端使用最终用户的用户id和密码以及自己的凭据请求访问令牌。此授予类型具有更高的风险，因为它维护UID/密码反模式。此外，由于用户无法控制授权过程，因此使用此授权类型的客户端不受限制
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.
而是具有与用户本身潜在相同的功能。由于没有授权步骤，因此无法提供令牌撤销。
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 授权服务器可以通过适当的媒介（如电子邮件）通知资源所有者已颁发的授权（见第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
o 授权服务器通常可能会拒绝在此流中发出刷新令牌（请参阅第5.2.2.1节）。如果特定的客户机是可信的，并且可以以可靠的方式进行身份验证（请参阅客户机身份验证），则授权服务器可以放松
that restriction. Resource owners may allow or deny (e.g., in their preferences) the issuing of refresh tokens using this flow as well.
这一限制。资源所有者也可以允许或拒绝（例如，在他们的首选项中）使用此流发出刷新令牌。
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".
攻击者可能会尝试使用授权类型“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节）以及nonce和时间戳来唯一标识请求。资源服务器应该检测并拒绝每个重播的请求。
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]依靠授权和WWW认证头来区分经过认证的内容，以便对其进行保护。特别是代理和缓存可能无法充分保护不使用这些头的请求。例如，私有认证内容可以存储在（因此可以从）可公开访问的缓存中。
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节）的客户端和资源服务器应注意使用缓存控制头，以最大限度地降低已验证内容不受保护的风险。此类客户端应发送包含“无存储”选项[RFC2616]的缓存控制标头。对这些请求的资源服务器成功（2XX状态）响应应包含带有“private”选项[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“referer”。
Countermeasures:
对策：
o Use Authorization headers or POST parameters instead of URI request parameters (see Section 5.4.1).
o 使用授权头或POST参数代替URI请求参数（参见第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]）可以减轻攻击。也可以考虑虚拟专用网络（VPN），例如基于IPsec VPN[RFC4301]。
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 重播在令牌的端点上获得的刷新令牌
o Replay of authorization "codes" obtained on the token's endpoint (redirect?)
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服务器身份验证或类似方法可用于验证服务器的身份。目标是将服务器的完全限定域名可靠地绑定到连接建立期间服务器提供的公钥（请参见[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 通知消息（如电子邮件、短信等）。请注意，通知可以是网络钓鱼载体。邮件应该是这样的，看起来相似的网络钓鱼邮件不能从中派生出来。
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.
授权服务器不应以明文形式存储凭据。典型的方法是存储哈希或加密凭据。如果凭证缺少合理的熵级别（因为它是用户密码），则额外的salt将使存储变硬，从而使脱机字典攻击更加困难。
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]）为此目的使用了受众元素。此对策可用于以下情况：
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对象表示法Web令牌（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.
授权服务器应将每个刷新令牌与向其发出刷新令牌的客户端的标识符相匹配。授权服务器应检查每个刷新访问令牌的请求是否存在相同的“客户端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\u 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.
授权服务器可能需要将认证凭证绑定到设备标识符。国际移动站设备标识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”，这两个值将分别阻止任何帧或具有不同原点的站点的任何帧。值“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.
由于不同客户机类型的不同功能和特点，有不同的方法来支持这些目标，本节将对此进行描述。授权服务器提供商应了解特定客户端的安全策略和部署，并相应地调整其处理方式。例如，一种方法可能是将所有客户视为不那么值得信任和不安全的客户。另一个极端是，服务提供商可以由管理员单独激活每个客户端安装，从而获得对软件包标识和客户端安装环境安全性的信心。在这两者之间有几种方法。
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:
授权服务器可以发出“客户机id”并将“客户机id”绑定到某个预先配置的“重定向uri”。具有另一个重定向URI的任何授权请求都将自动被拒绝。或者，授权服务器不应接受此类“客户端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应用程序，这可能意味着为安装软件包的每个网站创建一个“客户端id”和“客户端机密”。因此，该特定网站的提供商可以在网站设置期间从授权服务器请求客户端id和密码。这还允许验证该网站的某些属性，例如重定向URI、网站URL以及任何其他证明有用的属性。网站提供商必须确保网站上客户机密的安全性。
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
对于本机应用程序，情况更为复杂，因为任何设备上特定应用程序的每个副本都是不同的安装。此场景中的安装特定机密将需要获取“客户端id”和“客户端机密”
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.
以防止多次重播攻击。此外，特定于安装的“客户端ID”和机密允许一次选择性地撤销特定安装的所有刷新令牌。
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:
授权服务器应要求所有客户端注册其“重定向uri”，“重定向uri”应为[RFC6749]中定义的完整uri。执行此注册的方式不在本文档的范围内。根据核心规范，发送给最终用户授权端点的每个实际重定向URI以及相应的“client_id”必须与注册的重定向URI匹配。如果不匹配，授权服务器应假定入站GET请求已由攻击者发送并拒绝。注意：授权服务器不应将用户代理重定向回此类授权请求的重定向URI。验证预注册的“重定向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 通过假冒网站的授权“代码”泄漏：允许授权服务器在第一次重定向到最终用户授权端点后检测攻击企图（第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.
注意：在某些部署中，预注册客户端可能无法扩展（手动过程），或者需要动态客户端注册（尚未指定）。由于缺少动态客户端注册，预注册的“重定向uri”仅适用于在开发/配置时绑定到特定部署的客户端。一旦需要动态资源服务器发现，预注册的“重定向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. 使用强客户端身份验证（例如，客户端断言/客户端令牌）
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断言]，无需分发“客户机机密”。这可能需要使用安全私钥存储或客户端断言颁发者在其身份验证过程中指定的其他补充身份验证系统。
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).
授权服务器应向最终用户清楚地解释授权过程中发生的情况以及后果。例如，用户应该了解他将在多长时间内授予哪个客户端什么访问权限。对于用户来说，服务器是否能够可靠地验证某些客户端属性（网站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:
在授权过程中，通常要求用户批准客户的授权请求。这本身就是一个重要的安全机制，因为最终用户可以参与客户端属性的验证，例如授权服务器已知的客户端名称是否与网站或最终用户正在使用的应用程序的名称相符。在授权服务器无法对客户端进行身份验证的情况下，此度量尤其有用。这是针对以下情况的对策：
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 使用不同的客户端凭据重播授权“代码”，因为攻击者无法使用另一个“客户端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将授权“代码”交换到令牌中。
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).
“state”参数用于链接客户端请求并防止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代理和服务器识别和专门处理。因此，使用这样的报头向资源服务器发送访问令牌通常会降低已验证请求的泄漏或意外存储的可能性，尤其是授权报头。
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身份验证来验证其身份，资源服务器使用令牌引用的名称验证名称。
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:
资源服务器可能决定只接受已签名的请求，以取代传输级安全措施或补充此类措施。每个已签名的请求都应该是唯一可识别的，并且不应由资源服务器处理两次。这一对策有助于缓解：
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、许兰路、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.，“OAuth 2.0授权框架”，RFC 6749，2012年10月。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6750]Jones，M.和D.Hardt，“OAuth 2.0授权框架：承载令牌使用”，RFC 67502012年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第三届Web 2.0安全和隐私研讨会，2010年5月<http://elie.im/ 发布/bursting-frame-bursting-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，“国际移动站设备标识（IMEI）”，3GPP TS 22.016 11.0.01212年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.，和E.Maler，Ed.，“OASIS安全断言标记语言（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.，Ed.，Mishra，P.，Ed.，和R.Philpott，Ed.，“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.，和P.Mishra，Ed.，“sstc对“SAML单一登录浏览器/工件配置文件的安全性分析”的响应”，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断言]Campbell，B.，Mortimore，C.，Jones，M.，和Y.Goland，“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.，Ed.，Mills，W.，Ed.，和H.Tschofenig，Ed.，“OAuth 2.0消息认证码（MAC）令牌”，正在进行的工作，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.Sakimura，“JSON Web令牌（JWT）”，正在进行的工作，2012年12月。
[OAuth-REVOCATION] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "Token Revocation", Work in Progress, November 2012.
[OAuth撤销]Lodderstdt，T.，Ed.，Dronia，S.，和M.Scurtescu，“代币撤销”，正在进行的工作，2012年11月。
[OPENID] "OpenID Foundation Home Page", <http://openid.net/>.
[ OpenID ]“OpenID基金会主页”，<http://openid.net/>.
[OWASP] "Open Web Application Security Project Home Page", <https://www.owasp.org/>.
[OWASP]“打开Web应用程序安全项目主页”<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草稿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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，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，“安全的随机性要求”，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，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年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，“传输层安全（TLS）协议版本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单点登录浏览器/工件配置文件的安全分析”，第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]万维网联盟，“HTML文档中的框架”，W3C HTML 4.011999年12月<http://www.w3.org/TR/html4/present/frames.html#h-16.5>.
Authors' Addresses
作者地址
Torsten Lodderstedt (editor) Deutsche Telekom AG
Torsten Lodderstedt（编辑）德国电信公司
EMail: torsten@lodderstedt.net
EMail: torsten@lodderstedt.net
Mark McGloin IBM
马克·麦克格伦
EMail: mark.mcgloin@ie.ibm.com
EMail: mark.mcgloin@ie.ibm.com
Phil Hunt Oracle Corporation
菲尔亨特甲骨文公司
EMail: phil.hunt@yahoo.com
EMail: phil.hunt@yahoo.com