OAuth 2.0官方文档内容归纳

OAuth 2.0 授权框架

Abstract

OAuth 2.0授权框架使第三方应用程序能够代表资源所有者获得对HTTP服务的有限访问权，方法是协调资源所有者和HTTP服务之间的批准交互，或者允许第三方应用程序代表自己获得访问权。本规范取代并废除RFC 5849中描述的OAuth 1.0协议。

1. 介绍

OAuth通过引入授权层并将客户端角色与资源所有者角色分离来解决这些问题。在OAuth中，客户端请求访问由资源所有者控制并由资源服务器托管的资源，并且得到与资源所有者不同的一组凭据

客户机没有使用资源所有者的凭据来访问受保护的资源，而是获得一个访问令牌——一个表示特定范围、生存期和其他访问属性的字符串。通过资源所有者的批准，授权服务器将访问令牌发送给第三方客户端。客户端使用访问令牌访问由资源服务器托管的受保护资源。

例如，终端用户(资源所有者)可以授予打印
服务(客户)访问存储在照片共享服务(资源服务器)的受保护照片，而不与打印服务共享她的用户名和密码。相反，她直接通过照片共享服务信任的服务器进行身份验证(授权服务器)，它发出打印服务授权特定的凭据(访问令牌)。

此规范是为使用HTTP ([RFC2616])而设计的。在HTTP以外的任何协议上使用OAuth都超出了范围。

OAuth 2.0协议与OAuth 1.0不向后兼容。 这两个版本可以在网络上共存，实现也可以选择共存同时支持。然而，本规范的意图是，新的实现支持本文档中指定的OAuth 2.0，而OAuth 1.0仅用于支持现有的OAuth 1.0部署。OAuth 2.0协议与OAuth 1.0协议共享的实现细节很少。 熟悉OAuth 1.0的实现者应该阅读本文档，而不需要对其结构和细节做任何假设。

1.1 角色

OAuth定义了四种角色:

资源所有者
能够授予对受保护资源的访问权的实体。当资源所有者是人时，它被称为最终用户。

资源服务器
托管受保护资源的服务器，能够接受以及使用访问令牌响应受保护的资源请求。

客户端
代表资源所有者并通过其授权发出受保护资源请求的应用程序。术语“客户端”并不意味着任何特定的实现特征(例如，应用程序是在服务器、桌面还是其他设备上执行)。

授权服务器
服务器在成功地对资源所有者进行身份验证并获得授权后向客户机发出访问令牌。

1.2 协议流程

图片1-抽象协议流

( A ) 客户端向资源所有者请求授权。授权请求可以直接向资源所有者发出(如图所示)，最好是通过授权服务器作为中介间接发出。

( B ) 客户端收到一个授权授予，即表示资源所有者授权的凭据，使用其中定义的四种授予类型之一表示说明或使用扩展授权类型。授权授予类型取决于客户端请求授权的方法以及授权服务器支持的类型。

( C ) 客户端通过与授权服务器进行身份验证并提供授权授予来请求访问令牌。

( D ) 授权服务器对客户端进行身份验证并验证授权授予，如果有效，则发出一个访问令牌。

( E ) 客户机从资源服务器请求受保护的资源，并通过显示访问令牌进行身份验证。

( F ) 资源服务器验证访问令牌，如果有效，则为请求提供服务。

1.3 授权批准

授权授予是代表资源所有者授权(访问其受保护资源)的凭证，客户机使用它来获取访问令牌。该规范定义了四种授权类型——授权代码、隐式授权、资源所有者密码凭据和客户端凭据——以及用于定义其他类型的扩展机制。

1.3.1 授权代码

授权代码是通过使用授权服务器作为客户端和资源所有者之间的中介来获得的。客户机不是直接从资源所有者请求授权，而是将资源所有者定向到授权服务器(通过其user-agent在[RFC2616]中定义)，它反过来指导资源所有者使用授权代码返回客户机。

在使用授权代码将资源所有者指示回客户机之前，授权服务器对资源所有者，获取授权。因为资源所有者只通过授权服务器进行身份验证，所以资源所有者的凭据永远不会与客户机共享。

授权代码提供了一些重要的安全好处，例如能够对客户机进行身份验证，以及直接将访问令牌传输到客户机，而无需将其通过资源所有者的用户代理传递，并可能将其公开给包括资源所有者在内的其他人。

1.3.2 隐式授权

隐式授权是一种简化的授权代码流，针对使用JavaScript等脚本语言在浏览器中实现的客户机进行了优化。在隐式流中，不是向客户端发送授权代码，而是直接向客户端发送访问令牌(作为资源所有者授权的结果)。授权类型是隐式的，因为没有颁发中间凭据(例如授权代码)(稍后用于获取访问令牌)。

当在隐式授权流期间发出访问令牌时，授权服务器不对客户机进行身份验证。在某些情况下，可以通过用于将访问令牌传递给客户机的重定向URI来验证客户机标识。访问令牌可以公开给资源所有者或其他可以访问资源所有者的用户代理的应用程序。

隐式授权提高了一些客户机(例如实现为浏览器内应用程序的客户机)的响应能力和效率，因为它减少了获取访问令牌所需的往返次数。然而，这种便利应该与使用隐性授予的安全影响进行权衡，例如第10.3和10.16节中描述的那些，特别是当可以使用授权码授予类型。

1.3.3 资源所有者密码凭证

资源所有者密码凭据(即用户名和密码)可以直接作为授权使用，以获得访问令牌。只有当资源所有者和客户端之间存在高度信任(例如，客户端是设备操作系统或高度特权应用程序的一部分)，以及其他授权授予类型不存在时，才应该使用凭证可用(如授权代码)。尽管这种授权类型要求客户端直接访问资源所有者凭据，但资源所有者凭据用于单个请求，并用于交换访问令牌。这种授予类型可以消除客户端存储资源所有者凭据以备将来使用的需要，通过交换具有长寿命访问令牌或刷新令牌的凭据。

1.3.4 客户端凭证

当授权范围限于客户端控制下的受保护资源，或之前与授权服务器一起安排的受保护资源时，客户机凭据(或其他形式的客户机身份验证)可以用作授权授予。客户端凭据通常在客户端代表自己(客户端也是资源所有者)或请求访问受保护的资源时用作授权授予基于先前与授权服务器商定的授权的资源。

1.4 访问令牌

访问令牌是用于访问受保护资源的凭据。访问令牌是一个字符串，表示向客户端发出的授权。字符串对客户端通常是不透明的。令牌表示由资源所有者授予并由资源服务器和授权服务器强制执行的特定访问范围和持续时间。

令牌可以表示用于检索授权信息的标识符，或者可以以可验证的方式(即，由一些数据和签名组成的标记字符串)。为了让客户端使用令牌，可能需要额外的身份验证凭据，这超出了本规范的范围。

访问令牌提供了一个抽象层，用资源服务器可以理解的单个令牌替换不同的授权构造(例如，用户名和密码)。这种抽象使发出访问令牌比用于获得这些令牌的授权更具限制性，并且使资源服务器不再需要理解广泛的身份验证方法。

根据资源服务器的安全需求，访问令牌可以有不同的格式、结构和利用方法(例如，密码属性)。访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，由[RFC6750]等相关规范定义。

1.5 刷新令牌

刷新令牌是用于获取访问令牌的凭据。刷新令牌授权发布到客户机的服务器,用于获得一个新的访问令牌时,当前的访问令牌变得无效或过期,或获得额外的访问令牌相同或窄范围(访问权限令牌可能生存期较短,少于授权的资源所有者)。授权服务器可以自行决定是否发出刷新令牌。如果授权服务器发出一个刷新令牌，则在发出访问令牌(即，图1中的步骤(D)。

刷新令牌是一个字符串，表示资源所有者授予客户机的授权。字符串对客户端通常是不透明的。令牌表示用于检索授权信息。与访问令牌不同，刷新令牌仅用于授权服务器，从不发送到资源服务器。

图片2-刷新过期的访问令牌

图2所示的流程包括以下步骤:

( A )客户机通过身份验证请求访问令牌授权服务器并呈现授权授予。

( B )授权服务器对客户端进行身份验证并验证授权授予，如果有效，则发出一个访问令牌和一个刷新令牌。

( C )客户机通过显示访问令牌向资源服务器发出受保护的资源请求。

( D )资源服务器验证访问令牌，如果有效，则为请求提供服务。

( E )步骤( C )和( D )重复，直到访问令牌过期。如果客户端知道访问令牌过期，则跳到步骤( G );否则，它将发出另一个受保护的资源请求。

( F )由于访问令牌无效，资源服务器返回一个无效令牌错误

1.6 TLS版本

每当传输层安全(TLS)被使用时规范，TLS的适当版本(或多个版本)将随着时间的推移而变化，基于广泛的部署和已知的安全漏洞。在撰写本文时，TLS版本为1.2[RFC5246]是最新的版本，但是有一个非常有限的部署基地，可能不容易得到实现。TLS版本1.0 [RFC2246]是最广泛的已部署的版本，将提供最广泛的互操作性。实现还可能支持满足其安全需求的额外传输层安全机制。

1.7 HTTP重定向

该规范大量使用HTTP重定向，其中客户机或授权服务器将资源所有者的用户代理定向到另一个目的地。而这里的例子规范显示了HTTP 302状态码的使用，任何其他通过用户代理可用的方法来完成此重定向是允许的，并被认为是实现细节。

1.8 互操作性

OAuth 2.0提供了一个具有定义良好的安全属性的丰富授权框架。然而，作为一个具有许多可选组件的丰富的和高度可扩展的框架，它本身规范很可能产生广泛的非互操作实现。

此外，该规范还保留了一些部分或完全未定义的必需组件(例如，客户端注册、授权服务器功能、端点发现)。没有这些组件、客户机必须针对特定的授权服务器和资源服务器手工配置，以便进行互操作。

这个框架的设计有一个明确的预期，即未来的工作将定义规范的配置文件和必要的扩展，以实现完全网络规模的互操作性。

1.9 符号约定

本规范中的“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”、“OPTIONAL”等关键词按[RFC2119]解释。本规范使用增强巴克斯-诺尔形式(ABNF)符号(RFC5234)。此外，规则URI引用包含在“统一资源标识符(URI):通用语法”[RFC3986]中。

某些与安全相关的术语需要按照[RFC4949]中定义的意义来理解。这些术语包括但不限于“攻击”、“身份验证”、“授权”、“证书”、“机密性”、“凭证”、“加密”、“身份”、“签名”、“签名”、“信任”、“验证”和“验证”。

除非特别说明，所有协议参数名称和值都是大小写敏感的。

2 客户端注册

在启动协议之前，客户端向授权服务器。客户机向授权服务器注册的方法不在此范围之内规范，但通常涉及最终用户与HTML注册表单的交互。客户端注册不需要客户端和授权服务器之间的直接交互。当有授权服务器，注册可以依靠其他方式进行建立信任并获得所需的客户端属性(例如，重定向URI、客户端类型)。例如，注册可以使用自发出或第三方发出的断言完成，也可以由授权服务器使用可信通道执行客户机发现。

登记委托方时，委托方开发者应:

• 指定第2.1条所述的客户类型
• 提供3.1.2节中描述的客户端重定向uri，以及
• 包括授权服务器要求的任何其他信息(例如，应用名称、网站、描述、标识图像、对法律术语的接受)。

2.1 客户端类型

OAuth根据它们的能力定义了两种客户机类型使用授权服务器(即能够保持客户证书的机密性):

• 保密
  有能力保密的客户凭据(例如，在安全服务器上实现的客户机，对客户机凭据的访问受到限制)，或者能够使用其他方法进行安全客户机身份验证。
• 公共
  客户端无法维护其凭据的机密性(例如，在资源所有者使用的设备上执行的客户端，例如安装的本地应用程序或基于web浏览器的应用程序)，并且无法通过任何其他方式进行安全的客户端身份验证。

客户端类型的指定基于授权服务器的安全身份验证定义及其可接受的客户端凭据公开级别。授权服务器不应该对客户端类型做出假设。

客户端可以实现为一组分布式组件，每个组件都有不同的客户端类型和安全上下文(例如，A分布式客户机，包含一个机密的基于服务器的组件和一个公共的基于浏览器的组件)。如果授权服务器不提供对此类客户端的支持或不提供关于他们的注册指导，客户应该将每个组件注册为一个单独的客户机。

本规范围绕以下客户配置文件进行设计:

• web应用程序
  一个web应用程序是一个运行在web服务器上的机密客户机。资源所有者通过在资源所有者使用的设备上的用户代理中呈现的HTML用户界面访问客户端。客户端凭据以及发送给客户端的任何访问令牌都存储在web服务器上，资源所有者不会公开或访问这些令牌。
• user-agent-based应用程序
  基于用户代理的应用程序是一个公共客户端，其中客户端代码从web服务器下载，并在资源所有者使用的设备上的用户代理(如web浏览器)中执行。协议数据和凭据对于资源所有者来说很容易访问(而且通常是可见的)。由于此类应用程序驻留在用户代理中，因此它们可以在请求授权时无缝地使用用户代理功能。
• 本机应用程序
  本机应用程序是在资源所有者使用的设备上安装和执行的公共客户端。协议数据和资源所有者可以访问凭证。中包含的任何客户端身份验证凭据都被假定可以提取应用程序。另一方面，动态发布的凭据(如访问令牌或刷新令牌)可以获得可接受的保护级别。至少，保护这些凭证不受应用程序可能与之交互的敌对服务器的攻击。在某些平台上，这些凭据可能受到保护，不受同一设备上的其他应用程序的影响。

2.2 客户机标识符

授权服务器向已注册的客户机发出一个客户机标识符——表示注册的惟一字符串客户提供的信息。客户端标识符不是秘密;它向资源所有者公开，并且绝不能单独用于客户端身份验证。客户机标识符对于授权服务器是唯一的。

客户端标识符字符串大小因此未定义规范。客户端应该避免假设标识符的大小。授权服务器应该记录它发出的任何标识符的大小。

2.3 客户端身份验证

如果客户端类型是保密的，客户端和授权服务器会建立一种适合授权服务器安全需求的客户端认证方式。授权服务器可以接受满足其安全要求的任何形式的客户端身份验证。

机密客户端通常被发放(或建立)一组客户端凭据，用于与授权服务器进行身份验证(例如，密码、公钥/私钥对)。

授权服务器可以建立具有公共客户端的客户端身份验证方法。但是，授权服务器必须不依赖公共客户端身份验证来标识客户端。

客户端不能在每个请求中使用多个身份验证方法。

2.3.1 客户密码

拥有客户端密码的客户端可以使用[RFC2617]中定义的HTTP基本身份验证方案与授权服务器进行身份验证。客户机标识符使用“application/x-www-form-urlencoded”编码算法附录B，编码后的值用作用户名;客户端密码使用相同的算法进行编码，并作为密码。授权服务器必须支持HTTP基本身份验证方案，以便对发送了客户端密码的客户端进行身份验证。

例如(额外的换行符仅用于显示目的):

授权:基本的czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
或者，授权服务器可能支持通过以下方式在请求体中包含客户端凭据参数:

• client_id
  必需的。在第2.2节描述的注册过程中颁发给客户端的客户标识符。
• client_secret
  必需的。客户的秘密。如果客户端秘密是一个空字符串，客户端可以省略该参数。

不建议使用这两个参数在请求体中包含客户机凭据，并且应该仅限于无法直接使用HTTP基本身份验证方案(或其他基于密码的HTTP身份验证方案)的客户机。参数只能在请求体中传输，并且不能包含在请求URI中。

例如，使用body参数刷新访问令牌(第6节)的请求(额外的换行符仅用于显示目的):

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

当使用密码身份验证发送请求时，授权服务器必须要求使用章节1.6所述的TLS。由于这种客户机身份验证方法涉及一个密码，授权服务器必须保护使用它的任何端点免受暴力破解攻击。

2.3.2 其他身份验证方法

授权服务器可以支持任何匹配其安全需求的合适的HTTP身份验证方案。当使用其他认证方法，授权服务器必须定义一个客户端标识符(注册记录)和身份验证方案之间的映射。

2.4 未注册客户

此规范不排除未注册客户端的使用。然而，此类客户机的使用超出了本文的范围规范，并要求对其互操作性影响进行额外的安全性分析和审查。

3 协议的端点

授权过程使用两个授权服务器端点(HTTP资源):

• 授权端点——由客户端用于获取资源所有者通过用户-代理重定向进行授权。
• 令牌端点——由客户端用于交换访问令牌的授权授权，通常使用客户端身份验证。

以及一个客户端端点:

• 重定向端点——由授权服务器使用，通过资源所有者user-agent向客户端返回包含授权凭据的响应。

并不是每种授权授予类型都使用两个端点。扩展补助金类型可以根据需要定义其他端点。

3.1 授权端点

授权端点用于与资源所有者交互并获得授权授予。授权服务器必须首先验证资源所有者的身份。授权服务器对资源所有者进行身份验证的方式(例如，用户名和密码登录、会话cookie)超出了本规范的范围。

客户机获取授权端点位置的方法超出了本规范的范围，但是位置通常在服务文档中提供。

端点URI可能包含一个“application/x-www-form-urlencoded”格式的(根据附录B)查询组件([RFC3986]第3.4节)，在添加额外的查询参数时必须保留它。端点URI必须不包含片段组件。

因为对授权端点的请求会导致user认证和明文凭证的传输(在HTTP响应中)，授权服务器在向服务器发送请求时必须使用章节1.6所述的TLS授权端点。

授权服务器必须支持对授权端点使用HTTP“GET”方法[RFC2616]，并且可能也支持使用“POST”方法。

不带值发送的参数必须被视为从请求中删除。授权服务器必须忽略无法识别的请求参数。请求和响应参数不能包含超过一次。

3.1.1 响应类型

授权端点由授权代码授权类型和隐式授权类型流使用。客户通知
使用以下参数指定所需授权类型的授权服务器

response_type
必需的。该值必须是第4.1.1节描述的请求授权码的“code”，第4.2.1节描述的请求访问令牌(隐式授权)的“token”，或者第8.4节描述的注册扩展值中的一个。

扩展响应类型可以包含一个以空格分隔(%x20)的值列表，其中值的顺序无关紧要(例如，响应类型“a b”与“b a”相同)。这些复合响应类型的含义由它们各自的规范定义。

如果授权请求缺少“response_type”参数，或者不理解响应类型，授权服务器必须返回4.1.2.1节中描述的错误响应。

3.1.2 重定向端点

在完成与资源所有者的交互之后，授权服务器将资源所有者的用户代理定向回客户机。授权服务器将用户代理重定向到客户机的重定向端点在客户端注册过程中或在发出授权请求时使用授权服务器。

重定向端点URI必须是[RFC3986]章节4.3定义的绝对URI。端点URI可以包括"application/x-www-form-urlencoded"格式的(根据附录B)查询组件([RFC3986]第3.4节)，在添加额外的查询参数时必须保留。端点URI必须不包含片段组件。

3.1.2.1 端点的请求保密

当请求的响应类型是“代码”或“令牌”时，或者当重定向请求将导致在开放网络上传输敏感凭据时，重定向端点应该要求使用章节1.6中描述的TLS。此规范并不强制使用TLS，因为在撰写本文时，要求客户机部署TLS对许多客户机开发人员来说是一个重大障碍。如果TLS不可用，授权服务器应该在重定向之前警告资源所有者不安全的端点(例如，在授权期间显示一条消息请求)。

缺乏传输层安全性可能会严重影响客户机及其被授权访问的受保护资源的安全性。当授权过程被用作一种形式时，传输层安全性的使用尤其关键由客户机委托的最终用户身份验证(例如，第三方登录服务)。

3.1.2.2 注册要求

授权服务器必须要求以下客户端注册他们的重定向端点:

• 公共客户。
• 使用隐性授予类型的保密客户。

授权服务器应该要求所有客户机在使用授权端点之前注册它们的重定向端点。

授权服务器应该要求客户机提供完整的重定向URI(客户机可以使用“state”请求参数来实现每个请求的定制)。如果不可能要求注册完整的重定向URI，授权服务器应该要求注册URI方案、授权机构和路径(允许客户端在请求授权时只动态更改重定向URI的查询组件)。

授权服务器可能允许客户端注册多个重定向端点。

缺少重定向URI注册要求可以使攻击者使用授权端点作为开放重定向器，如章节10.15所述。

3.1.2.3 动态配置

如果注册了多个重定向URI，如果只注册了重定向URI的一部分，或者没有注册重定向URI，客户端必须使用“redirect_uri”请求参数在授权请求中包含一个重定向URI。

当授权请求中包含重定向URI时，授权服务器必须比较和匹配接收到的值

对于[RFC3986] Section 6中定义的至少一个注册的重定向URI(或URI组件)，如果有任何重定向URI被注册。如果客户端注册包含完整的重定向URI，授权服务器必须使用[RFC3986]章节6.2.1中定义的简单字符串比较来比较两个URI。

3.1.2.4 无效的端点

如果一个授权请求由于缺失而无法验证，无效或不匹配重定向URI时，授权服务器应该通知资源所有者这个错误，并且绝对不能自动将用户代理重定向到无效的重定向URI。

3.1.2.5 端点的内容

到客户机端点的重定向请求通常会导致HTML文档响应，由用户代理处理。如果HTML响应直接作为重定向请求的结果，则HTML文档中包含的任何脚本都将在完全访问重定向URI及其包含的凭证的情况下执行。

客户端不应该在重定向端点响应中包含任何第三方脚本(例如，第三方分析、社交插件、广告网络)。相反，它应该从URI中提取凭据，并将用户代理再次重定向到另一个端点，而不公开凭据(在URI中或其他地方)。如果包含第三方脚本，客户机必须确保其自己的脚本(用于从URI中提取和删除凭证)将被包含先执行。

3.2 令牌端点

客户端使用令牌端点通过呈现其授权授予或刷新令牌来获取访问令牌。对象之外的所有授权授予都使用令牌端点隐式授权类型(因为访问令牌是直接发出的)。

客户端获取令牌端点位置的方法超出了本规范的范围，但是位置通常在服务文档中提供。

端点URI可能包含一个“application/x-www-form-urlencoded”格式的(根据附录B)查询组件([RFC3986]第3.4节)，在添加额外的查询参数时必须保留它。端点URI必须不包含片段组件。

由于对令牌端点的请求会导致纯文本凭证的传输(在HTTP请求和响应中)，授权服务器在向令牌端点发送请求时必须要求使用章节1.6中描述的TLS。

客户端在发出访问令牌请求时必须使用HTTP“POST”方法。

不带值发送的参数必须被视为从请求中删除。授权服务器必须忽略无法识别的请求参数。请求和响应参数不能包含超过一次。

3.2.1 客户端身份验证

机密客户机或其他已发出客户机凭据的客户机必须通过授权服务器进行身份验证，如中所述

第2.3节，当向令牌端点发出请求时。客户端认证主要用于:

• 强制将刷新令牌和授权码绑定到它们被发送到的客户端。当授权代码通过不安全的通道传输到重定向端点时，或者当重定向URI未完全注册时，客户机身份验证非常关键。
• 通过禁用客户端或更改其凭据从受到威胁的客户端中恢复，从而防止攻击者滥用被盗的刷新令牌。更改一组客户端凭据比撤销整个刷新令牌组要快得多。
• 实现认证管理最佳实践，这需要定期的证书轮换。旋转一组完整的刷新令牌可能很困难，而旋转一组客户端凭据要容易得多。

当客户端向令牌端点发送请求时，客户端可以使用“client_id”请求参数来标识自己。在“authorization_code”“grant_type”请求到令牌端点时，未经身份验证的客户端必须发送它的“client_id”，以防止自己无意中接受为具有不同“client_id”的客户端准备的代码。这可以保护客户端不被替换身份验证代码。(它没有为受保护的资源提供额外的安全性。)

3.3 访问令牌的范围

授权和令牌端点允许客户机使用“scope”请求参数指定访问请求的范围。接着，授权服务器使用“scope”响应参数通知客户机所发出的访问令牌的范围。

scope参数的值表示为一组以空格分隔、区分大小写的字符串。字符串由授权服务器定义。如果值包含多个空格分隔的字符串，那么它们的顺序无关紧要，并且每个字符串都添加一个请求范围之外的其他访问范围。

scope = scope-token *( SP scope-token )

scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

授权服务器可以根据授权服务器策略或资源所有者的指令完全或部分忽略客户端请求的范围。如果发出的访问令牌范围与客户端请求的范围不同，授权服务器必须包含“scope”响应参数，以通知客户端所授予的实际范围。

如果客户端在请求时省略了scope参数授权时，授权服务器必须使用预定义的默认值处理请求，否则无法通过指示无效范围的请求。授权服务器应该记录其范围要求和默认值(如果已定义)。

4 获得授权

要请求访问令牌，客户端需要从资源所有者那里获得授权。授权以授权授予的形式表示，客户机使用授权授予来请求访问令牌。OAuth定义了四种授权类型:授权代码、隐式授权、资源所有者密码凭证和客户端凭证。它还提供了定义额外授权类型的扩展机制。

4.1 授权代码授予（这一章有详细说明参数）

授权码授予类型用于获取访问令牌和刷新令牌，并针对机密客户端进行了优化。由于这是一个基于重定向的流，客户机必须能够与资源所有者的用户代理(通常是一个web浏览器)交互，并且能够接收来自授权服务器的传入请求(通过重定向)。

图片3-授权代码流

注意:说明步骤( A )、( B )和( C )的行在通过用户代理时被分成两部分。

图3所示的流程包括以下步骤:

( A )客户机通过将资源所有者的用户代理定向到授权端点来启动流。客户机包括它的客户机标识符、请求的范围、本地状态和一个重定向URI，授权服务器将在授权(或拒绝)访问时将用户代理发送回该URI。

( B )授权服务器验证资源所有者(通过用户代理)，并确定资源所有者是授予还是拒绝客户端的访问请求。

( C )假设资源所有者授予访问权限，授权服务器使用前面提供的重定向URI将用户代理重定向回客户机(在请求中或在客户机注册期间)。重定向URI包括授权代码和客户端先前提供的任何本地状态。

( D )客户机通过包含上一步中接收到的授权代码，从授权服务器的令牌端点请求访问令牌。当发出请求时，客户机通过授权服务器进行身份验证。客户端包含用于获取用于验证的授权代码的重定向URI。

( E )授权服务器对客户端进行身份验证，验证授权代码，并确保重定向URI。received匹配用于重定向客户机的URI。step©如果有效，授权服务器将使用访问令牌和刷新令牌(可选)进行响应。

4.1.1 授权请求

客户端通过添加以下内容来构造请求URI

参数使用“application/x-www-form-urlencoded”格式发送到授权端点URI的查询组件，参见附录B:

·response_type
必需的。Value必须设置为“code”。

·client_id
必需的。2.2节中描述的客户标识符。

·redirect_uri
可选的。如第3.1.2节所述。

·scope
可选的。第3.3节所述的访问请求范围。

·state
推荐。客户端用来维护请求和回调之间的状态的不透明值。授权服务器在将用户代理重定向回客户端时包含此值。这个参数应该被用来防止在10.12节中描述的跨站点请求伪造。

客户端使用HTTP重定向响应或通过用户代理可用的其他方式将资源所有者定向到构造的URI。

例如，客户端指示用户代理使用TLS(额外的换行符仅用于显示目的)发出以下HTTP请求:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

授权服务器验证请求，以确保所有必需的参数都存在且有效。如果请求有效，授权服务器对资源所有者进行身份验证，并获得授权决策(通过询问资源所有者或通过其他方式建立批准)。

当建立决策时，授权服务器使用HTTP重定向响应或通过用户代理可用的其他方式将用户代理定向到提供的客户机重定向URI。

4.1.2 授权响应

如果资源所有者授予访问请求，授权服务器发出授权代码，并通过向查询组件添加以下参数将其发送给客户机

根据附录B，使用"application/x-www-form-urlencoded"格式重定向URI:

·code
必需的。生成的授权代码授权服务器。
授权代码必须在发布后不久过期，以减少泄露的风险。授权代码的最大生存时间为10分钟
推荐的。客户端不能使用授权代码。不止一次。如果一个授权代码被多次使用，授权服务器必须拒绝该请求，并且应该(在可能的情况下)撤销以前基于该授权代码发出的所有令牌。授权代码绑定到客户端标识符和重定向URI。

·state
必需的。如果“state”参数在客户端授权请求中存在。从客户端接收到的准确值。

例如，授权服务器通过发送以下HTTP响应重定向用户代理:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

客户端必须忽略无法识别的响应参数。授权代码字符串的大小没有定义规范。客户端应该避免对代码值大小做出假设。授权服务器应该记录它发出的任何值的大小。

4.1.2.1 错误响应

如果请求由于缺少、无效或不匹配的重定向URI而失败，或者如果客户端标识符丢失或无效，授权服务器应该通知资源所有者这个错误，并且决不能自动将用户代理重定向到无效的重定向URI。

如果资源所有者拒绝访问请求或者请求失败的原因除了缺失或无效的重定向的URI,授权服务器通知客户端通过添加以下参数的查询组件重定向URI使用"application/x-www-form-urlencoded"格式,每个附录B:

·error
必需的。一个单一的ASCII [USASCII]错误码：

• invalid_request
  请求缺少必需的参数、包含无效的参数值、包含多个参数或格式不正确。
• unauthorized_client
  客户端无权使用此方法请求授权代码。
• access_denied
  资源所有者或授权服务器拒绝了该请求。
• unsupported_response_type
  授权服务器不支持通过该方式获取授权码。
• invalid_scope
  请求的范围无效、未知或格式不正确。
• server_error
  授权服务器遇到了意想不到的条件，阻止它完成请求。(这个错误码是必需的，因为500内部服务器错误HTTP状态码不能通过HTTP重定向返回给客户端。)
• temporarily_unavailable
  由于服务器临时过载或维护，授权服务器目前无法处理请求。(此错误代码是必需的，因为503服务不可用HTTP状态码无法通过HTTP重定向返回给客户端。)

“error”参数的值必须不包含设置%x20-21 / %x23-5B / %x5D-7E之外的字符。

·error_description
可选的。人类可读的ASCII [USASCII]文本提供额外的信息，用于帮助客户端开发人员理解发生的错误。"error_description"参数的值必须不包含设置%x20-21 / %x23-5B / %x5D-7E之外的字符。

·error_uri
可选的。标识带有错误信息的人类可读网页的URI，用于向客户端开发人员提供关于错误的附加信息。"error_uri"参数的值必须符合uri引用语法，因此不能包含集合%x21 / %x23-5B / %x5D-7E之外的字符。

·state
必需的。如果客户端授权请求中存在一个“state”参数，从客户端接收到的准确值。

例如，授权服务器通过发送以下HTTP响应重定向用户代理:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz

4.1.3 访问令牌的请求

客户端通过在HTTP请求实体体中使用UTF-8字符编码的“application/x-www-form-urlencoded”格式每个附录B发送以下参数向令牌端点发出请求:

• grant_type
  必需的。Value必须设置为“authorization_code”。
• code
  必需的。从授权服务器接收的授权码。
• redirect_uri
  必需的。如果“redirect_uri”参数包含在第4.1.1节中描述的授权请求中，并且它们的值必须相同。
• client_id
  必需的。如果客户端没有与授权服务器进行认证，如3.2.1节所述。

如果客户端类型是保密的，或者客户端被颁发了客户端凭证(或分配了其他身份验证要求)，客户端必须通过第3.2.1节中描述的授权服务器进行身份验证。

例如，客户端使用TLS(额外的换行符仅用于显示目的)发出以下HTTP请求:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

授权服务器必须:

• 要求对机密客户或任何已发出客户凭据(或与其他客户)的客户进行身份验证
• 如果包括客户端身份验证，则对客户端进行身份验证
• 确保授权码被颁发给经过身份验证的机密客户端，或者如果客户端是公共的，确保授权码被颁发给请求中的“client_id”
• 确保“redirect_uri”参数存在，如果初始授权中包含“redirect_uri”参数。如第 4.1.1 节所述请求，如果包含，请确保它们的值是相同的。

4.1.4 访问令牌响应

如果访问令牌请求有效且已授权，则授权服务器发出访问令牌和可选刷新令牌，如第5.1节所述。
如果请求客户端认证失败或无效，授权服务器返回一个错误响应，如章节5.2所述。
一个成功的例子:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

4.2 隐式授权

隐式授权类型用于获取访问令牌(它不支持发布刷新令牌)，并针对已知操作特定重定向URI的公共客户端进行了优化。这些客户机通常使用脚本语言(如JavaScript)在浏览器中实现。

由于这是一个基于重定向的流，客户机必须能够与资源所有者的用户代理(通常是一个web浏览器)交互，并且能够接收来自授权服务器的传入请求(通过重定向)。

与授权代码授权类型不同(在授权代码授权类型中，客户端分别请求授权和访问令牌)，客户端接收作为授权请求结果的访问令牌。

隐式授予类型不包括客户端身份验证，它依赖于资源所有者的存在和重定向URI的注册。因为访问令牌被编码到重定向URI中，所以它可能向资源所有者和驻留在同一设备上的其他应用程序公开。

图片4-隐式授权流程

注意：说明步骤(A)和(B)的行在通过用户代理时被分成两部分。

图 4 所示的流程包括以下步骤：
(A)客户机通过将资源所有者的用户代理定向到授权端点来启动流。客户机包括它的客户机标识符、请求的范围、本地状态和一个重定向URI，授权服务器将在授权(或拒绝)访问时将用户代理发送回该URI。
(B)授权服务器验证资源所有者(通过用户代理)，并确定资源所有者是授予还是拒绝客户端的访问请求。
©假设资源所有者授予访问权限，授权服务器使用前面提供的重定向URI将用户代理重定向回客户机。重定向URI在URI片段中包含访问令牌。
(D)用户代理遵循重定向指令，向web托管的客户端资源发出请求（不包括每个 [ RFC2616 ] 的片段）。用户代理保留在本地分段信息。
(E)web托管的客户端资源返回一个web页面(通常是一个带有嵌入式脚本的HTML文档)，能够访问完整的重定向URI，包括由用户代理保留的片段，并提取访问令牌(以及其他)
参数)包含在片段中。
(F)用户代理在本地执行web托管客户端资源提供的脚本，该脚本提取访问令牌。
(G)用户代理将访问令牌传递给客户端。

关于使用隐性授予的背景，请参见第1.3.2节和第9节。使用隐式授权时的重要安全考虑请参见10.3和10.16节。

4.2.1 授权请求

客户端通过添加以下内容来构造请求 URI，授权端点 URI 的查询组件的参数根据附录 B，使用“application/x-www-form-urlencoded”格式：

• response_type
  必需的。值必须设置为“令牌”。
• client_id
  必需的。2.2 节中描述的客户端标识符。
• redirect_uri
  可选的。如第 3.1.2 节所述。
• scope
  可选的。第3.3节所述的访问请求范围。
• state
  推荐。客户端用来维护请求和回调之间的状态的不透明值。授权服务器在将用户代理重定向回客户端时包含此值。这个参数应该被用来防止在10.12节中描述的跨站点请求伪造。

客户端使用HTTP重定向响应或通过用户代理可用的其他方式将资源所有者定向到构造的URI。

例如，客户端指示用户代理使用TLS(额外的换行符仅用于显示目的)发出以下HTTP请求:

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

授权服务器验证请求，以确保所有必需的参数都存在且有效。授权服务器必须验证它将访问令牌重定向到的重定向URI与客户端在章节3.1.2中所描述的重定向URI匹配。

如果请求有效，授权服务器对资源所有者进行身份验证，并获得授权决策(通过询问资源所有者或通过其他方式建立批准)。

当建立决策时，授权服务器使用HTTP重定向响应或通过用户代理可用的其他方式将用户代理定向到提供的客户机重定向URI。