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
        
1. Introduction
1. 介绍

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规范的基础,所以它不考虑诸如客户端注册或发现之类的建议扩展,其中许多仍在讨论中。

2. Overview
2. 概述
2.1. Scope
2.1. 范围

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。

2.2. Attack Assumptions
2.2. 攻击假设

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协议的三方中的两方可能串通对第三方发起攻击。例如,客户端和授权服务器可能受到攻击者的控制,并串通欺骗用户以获得对资源的访问。

2.3. Architectural Assumptions
2.3. 架构假设

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协议使部署在如何实现和应用该标准方面有一定的自由度。核心规范定义了授权服务器和资源服务器的核心概念。两台服务器可以在同一个服务器实体中实现,也可以是不同的实体。后者通常适用于具有单一身份验证和授权系统的多服务提供商,在中间件体系结构中更为典型。

2.3.1. Authorization Servers
2.3.1. 授权服务器

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”、授权“代码”

2.3.2. Resource Server
2.3.2. 资源服务器

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.

假设资源服务器不知道刷新令牌、用户密码或客户端机密。

2.3.3. Client
2.3.3. 客户

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”,授权“代码”

3. Security Features
3. 安全特性

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协议中内置的一些安全特性,用于缓解攻击和安全问题。

3.1. Tokens
3.1. 代币

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])相对应的密钥对资源请求进行数字签名。

3.1.1. Scope
3.1.1. 范围

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客户端的资源的访问,这些客户端认为这些客户端不太安全或不可信。可选地,客户机可以请求将作用域应用于令牌,但仅适用于比以其他方式授予的作用域更小的作用域,例如,如果通过非安全通道发送该令牌,则减少潜在影响。作用域通常由对令牌生存期的限制来补充。

3.1.2. Limited Access Token Lifetime
3.1.2. 有限访问令牌生存期

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客户端发出短期令牌。

3.2. Access Token
3.2. 访问令牌

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.

客户端使用访问令牌访问资源。访问令牌通常具有较短的生命周期(分钟或小时),涵盖典型的会话生命周期。可以通过使用刷新令牌来刷新访问令牌。接入令牌的短寿命与刷新令牌的使用相结合,使得能够在当前接入令牌到期时被动撤销接入授权。

3.3. Refresh Token
3.3. 刷新令牌

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.

因此,只要客户机可以确保特定令牌的机密性,刷新令牌也可以用作认证客户机实例本身的替代手段。

3.4. Authorization "code"
3.4. 授权“代码”

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. 在客户机和授权服务器之间的直接请求期间对客户机进行身份验证要比在间接授权请求的上下文中简单得多。后者需要数字签名。

3.5. Redirect URI
3.5. 重定向URI

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进行验证。

3.6. "state" Parameter
3.6. “状态”参数

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规范,用户代理必须能够将其保留在仅由客户端和用户代理访问的位置,即受同源策略保护。

3.7. Client Identifier
3.7. 客户端标识

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”,授权服务器可在后续请求事务中识别此类客户机(例如,授权和令牌颁发、刷新令牌颁发和访问令牌刷新)。授权服务器无法向最终用户保证客户端的任何属性。也可以允许自动处理重新授权。这样的客户端凭据可以自动生成,而无需对客户端属性进行任何验证,这使它成为另一种选择,特别是对于本机应用程序。撤销将仅影响单个部署。

4. Threat Model
4. 威胁模型

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节中的详细描述。

4.1. Clients
4.1. 客户

This section describes possible threats directed to OAuth clients.

本节描述针对OAuth客户端的可能威胁。

4.1.1. Threat: Obtaining Client Secrets
4.1.1. 威胁:获取客户机密

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节)。

4.1.2. Threat: Obtaining Refresh Tokens
4.1.2. 威胁:获取刷新令牌

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节)。

4.1.3. Threat: Obtaining Access Tokens
4.1.3. 威胁:获取访问令牌

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 客户端开发人员不应编写直接从用户收集身份验证信息的客户端应用程序,而应将此任务委托给受信任的系统组件,例如系统浏览器。

4.1.5. Threat: Open Redirectors on Client
4.1.5. 威胁:在客户端上打开重定向程序

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节)。

4.2. Authorization Endpoint
4.2. 授权端点
4.2.1. Threat: Password Phishing by Counterfeit Authorization Server
4.2.1. 威胁:伪造授权服务器的密码钓鱼

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 授权服务器应尝试让用户了解网络钓鱼攻击带来的风险,并应提供便于用户确认其网站真实性的机制。

4.2.2. Threat: User Unintentionally Grants Too Much Access Scope
4.2.2. 威胁:用户无意中授予了太多的访问范围

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节)。

4.2.3. Threat: Malicious Client Obtains Existing Authorization by Fraud
4.2.3. 威胁:恶意客户端通过欺诈获得现有授权

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节)。

4.2.4. Threat: Open Redirector
4.2.4. 威胁:打开重定向器

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节)。

4.3. Token Endpoint
4.3. 令牌端点
4.3.1. Threat: Eavesdropping Access Tokens
4.3.1. 威胁:窃听访问令牌

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节)。

4.3.3. Threat: Disclosure of Client Credentials during Transmission
4.3.3. 威胁:在传输过程中泄露客户端凭据

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节)正确处理凭证。

4.3.5. Threat: Obtaining Client Secret by Online Guessing
4.3.5. 威胁:通过在线猜测获取客户机密

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节)。

4.4. Obtaining Authorization
4.4. 获得授权

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.

本节介绍特定于用于获取访问令牌的特定流的威胁。每个流的特征分别是最终用户授权和令牌端点上的响应类型和/或授权类型。

4.4.1. Authorization "code"
4.4.1. 授权“代码”
4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"
4.4.1.1. 威胁:窃听或泄露授权“代码”

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节)。

4.4.1.3. Threat: Online Guessing of Authorization "codes"
4.4.1.3. 威胁:在线猜测授权“代码”

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节)。

4.4.1.4. Threat: Malicious Client Obtains Authorization
4.4.1.4. 威胁:恶意客户端获得授权

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节)。

4.4.1.5. Threat: Authorization "code" Phishing
4.4.1.5. 威胁:授权“代码”钓鱼

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节)。

4.4.1.6. Threat: User Session Impersonation
4.4.1.6. 威胁:用户会话模拟

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节)。

4.4.1.8. Threat: CSRF Attack against redirect-uri
4.4.1.8. 威胁:针对重定向uri的CSRF攻击

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。

4.4.1.9. Threat: Clickjacking Attack against Authorization
4.4.1.9. 威胁:针对授权的点击劫持攻击

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])技术,但并非在所有浏览器中都有效。

4.4.1.10. Threat: Resource Owner Impersonation
4.4.1.10. 威胁:资源所有者冒充

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.

或者,为了允许资源所有者检测滥用,授权服务器可以通过适当的方式(例如,文本或即时消息或电子邮件)通知资源所有者任何批准。

4.4.1.11. Threat: DoS Attacks That Exhaust Resources
4.4.1.11. 威胁:耗尽资源的DoS攻击

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 授权服务器应该在授权“代码”中包含大量的熵。

4.4.1.12. Threat: DoS Using Manufactured Authorization "codes"
4.4.1.12. 威胁:DoS使用制造的授权“代码”

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 acco