OAuth 2.0 快速指南

---

---

OAuth 2.0 - 概述

什么是 OAuth 2.0？

OAuth 是一种开放的授权协议，它允许客户端应用程序访问资源所有者的资源，方法是启用诸如 Facebook、GitHub 等 HTTP 服务上的客户端应用程序。它允许在不使用其凭据的情况下将存储在一个站点上的资源共享到另一个站点。它使用用户名和密码令牌代替。

OAuth 2.0 由 *IETF OAuth 工作组* 开发，于 2012 年 10 月发布。

为什么要使用 OAuth 2.0？

• 您可以使用 OAuth 2.0 从另一个应用程序读取用户的资料。

• 它为 Web、桌面应用程序和移动设备提供授权工作流程。

• 它是一个使用授权码的服务器端 Web 应用，并且不与用户凭据交互。

OAuth 2.0 的特性

• OAuth 2.0 是一种简单的协议，允许访问用户的资源而无需共享密码。

• 它为使用脚本语言（如 JavaScript）运行客户端应用程序提供用户代理流程。通常，浏览器是用户代理。

• 它使用令牌而不是使用其凭据来访问数据，并将数据存储在用户的在线文件系统中，例如 Google Docs 或 Dropbox 帐户。

OAuth 2.0 的优势

• OAuth 2.0 是一种非常灵活的协议，它依赖于 SSL（确保 Web 服务器和浏览器之间的数据保持私密的安全套接字层）来保存用户访问令牌。

• OAuth 2.0 依赖于 SSL，SSL 用于确保加密行业协议，并用于确保数据安全。

• 它允许有限地访问用户的数据，并在授权令牌过期时允许访问。

• 它能够在无需发布个人信息的情况下为用户共享数据。

• 它更容易实现并提供更强大的身份验证。

OAuth 2.0 的缺点

• 如果您在规范的末尾添加更多扩展，它将产生范围广泛的互操作性实现，这意味着您必须为 Facebook、Google 等编写单独的代码段。

• 如果您的收藏网站连接到中央枢纽，并且中央帐户被黑客入侵，那么它将导致多个网站而不是仅仅一个网站受到严重影响。

OAuth 2.0 - 架构

在本章中，我们将讨论 OAuth 2.0 的架构风格。

**步骤 1** - 首先，用户使用客户端应用程序（例如 Google、Facebook、Twitter 等）访问资源。

**步骤 2** - 接下来，在注册重定向 URI（统一资源标识符）期间，将向客户端应用程序提供客户端 ID 和客户端密码。

**步骤 3** - 用户使用身份验证应用程序登录。客户端 ID 和客户端密码对于授权服务器上的客户端应用程序是唯一的。

**步骤 4** - 身份验证服务器使用授权码将用户重定向到重定向统一资源标识符 (URI)。

**步骤 5** - 用户访问客户端应用程序中重定向 URI 处的页面。

**步骤 6** - 将向客户端应用程序提供身份验证代码、客户端 ID 和客户端密码，并将它们发送到授权服务器。

**步骤 7** - 身份验证应用程序将访问令牌返回给客户端应用程序。

**步骤 8** - 一旦客户端应用程序获得访问令牌，用户就开始使用客户端应用程序访问资源所有者的资源。

OAuth 2.0 有各种概念，在下表中简要解释。

OAuth 2.0 - 客户端凭据

当客户端是资源所有者时，或者当授权范围仅限于客户端控制下的受保护资源时，可以使用客户端凭据作为授权授予。

• 客户端仅在客户端凭据的帮助下请求访问令牌。

• 客户端凭据授权流程用于获取访问令牌以授权 API 请求。

• 使用客户端凭据授权，获取的访问令牌仅授予您的客户端应用程序搜索和获取目录文档的权限。

下图描绘了客户端凭据流程。

上图所示的流程包含以下步骤 -

**步骤 1** - 客户端向授权服务器进行身份验证，并向令牌端点请求访问令牌。

**步骤 2** - 授权服务器对客户端进行身份验证，如果客户端有效且已授权，则提供访问令牌。

下表列出了客户端凭据的概念。

OAuth 2.0 - 获取访问令牌

访问令牌是识别用户、应用程序或页面的字符串。令牌包含诸如令牌何时过期以及创建该令牌的应用程序等信息。

• 首先，有必要从 API 控制台获取 OAuth 2.0 客户端凭据。

• 然后，客户端向授权服务器请求访问令牌。

• 它从响应中获取访问令牌，并将令牌发送到您希望访问的 API。

您必须首先将用户发送到授权端点。以下是一个虚拟请求的示例

https://publicapi.example.com/oauth2/authorize?client_id=your_client_id&redirect_uri=your_url 
   &response_type=code

以下是参数及其描述。

• **client_id** - 应设置为应用程序的客户端 ID。

• **redirect_uri** - 应设置为 URL。授权请求后，用户将被重定向回。

• **response_type** - 可以是代码或令牌。代码必须用于服务器端应用程序，而令牌必须用于客户端应用程序。在服务器端应用程序中，您可以确保安全地保存机密。

下表列出了客户端凭据的概念。

OAuth 2.0 - 访问受保护的资源

客户端向资源服务器提供访问令牌以访问受保护的资源。资源服务器必须验证并确认访问令牌有效且未过期。

有两种标准的发送凭据方式 -

• **承载令牌** - 访问令牌只能放置在 POST 请求正文中或作为授权 HTTP 标头中的后备选项的 GET URL 参数中。

它们包含在授权标头中，如下所示 -

Authorization: Bearer [token-value]

例如 -

GET/resource/1 HTTP /1.1
Host: example.com
Authorization: Bearer abc...

• **MAC** - 使用请求的元素计算加密**消息认证码**(MAC)，并将其发送到授权标头。收到请求后，资源所有者会比较并计算 MAC。

下表显示了访问受保护资源的概念。

OAuth 2.0 - 可扩展性

可以定义访问令牌类型的两种方式 -

• 通过在访问令牌类型的注册表中注册。

• 通过使用唯一的绝对 URI（统一资源标识符）作为其名称。

定义新的端点参数

参数名称必须遵守 param-name ABNF（增强巴克斯-诺尔范式是一种基于巴克斯-诺尔范式的元语言，包含其自身的语法和派生规则），并且参数值的语法必须定义明确。

param-name = 1* name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA

定义新的授权授予类型

可以使用“grant_type”参数为新的授权授予类型分配一个不同的绝对 URI 以供使用。如果扩展授权授予类型需要其他令牌端点参数，则必须在 OAuth 参数注册表中注册。

定义新的授权端点响应类型

response-type = response-name *(SP response-name)
response-name = 1* response-char
response-char = "_" / DIGIT / ALPHA

如果响应类型具有一个或多个空格字符，则将其作为以空格分隔的值列表进行比较，其中值的顺序无关紧要，并且只能注册一个值的顺序。

定义其他错误代码

如果它们使用的扩展名是已注册的访问令牌或已注册的端点参数，则必须注册扩展错误代码。错误代码必须遵守 error ABNF（增强巴克斯-诺尔范式），并且在可能的情况下，它应该以识别它的名称作为前缀。

error = 1 * error_char
error-char =  %x20-21 / %x23-5B / 5D-7E

OAuth 2.0 - IANA 注意事项

IANA 代表**I**nternet **A**ssigned **N**umbers **A**uthority，它提供有关与**R**emote **A**uthentication **D**ial **I**n **U**ser **S**ervice (RADIUS) 相关的注册值的信息。

IANA 包括以下注意事项 -

OAuth 访问令牌类型注册表

OAuth 访问令牌由专家根据所需的规范进行注册。如果他们对注册结果满意，才会发布规范。注册请求将发送至 @ietf.org 进行审查，主题为“访问令牌类型请求：示例”。专家将在请求发出后的 14 天内拒绝或接受请求。

注册模板

注册模板包含以下规范：

• 类型名称 - 它是请求的名称。

• 令牌端点响应参数 - 额外的访问令牌响应参数将在 OAuth 参数注册表中单独注册。

• HTTP 身份验证方案 - HTTP 身份验证方案可用于使用访问令牌对资源进行身份验证。

• 变更控制者 - 对于标准跟踪 RFC，请将状态名称指定为“IETF”，对于其他情况，请使用负责方的名称。

• 规范文档 - 规范文档包含可用于检索文档副本的参数。

OAuth 参数注册表

OAuth 参数注册表包含专家根据所需规范对授权端点请求或响应、令牌端点请求或响应进行的注册。注册请求将发送给专家，如果他们对注册结果满意，则会发布规范。

注册模板

注册模板包含诸如类型名称、变更控制者和规范文档之类的规范，其定义与上述OAuth 访问令牌类型注册表部分相同，但以下规范除外：

参数使用位置 - 它指定参数的位置，例如授权请求或响应、令牌请求或响应。

初始注册表内容

下表显示了包含初始内容的 OAuth 参数注册表：

OAuth 授权端点响应类型注册表

这可用于定义 OAuth 授权端点响应类型注册表。响应类型由专家根据所需的规范进行注册，如果他们对注册结果满意，才会发布规范。注册请求将发送至 @ietf.org 进行审查。专家将在请求发出后的 14 天内拒绝或接受请求。

注册模板

注册模板包含诸如类型名称、变更控制者和规范文档之类的规范，其定义与上述OAuth 访问令牌类型注册表部分相同。

初始注册表内容

下表显示了包含初始内容的授权端点响应类型注册表。

OAuth 扩展错误注册表

这可用于定义 OAuth 扩展错误注册表。错误代码以及协议扩展（例如授权类型、令牌类型等）由专家根据所需的规范进行注册。如果他们对注册结果满意，才会发布规范。注册请求将发送至 @ietf.org 进行审查，主题为“错误代码请求：示例”。专家将在请求发出后的 14 天内拒绝或接受请求。

注册模板

注册模板包含诸如变更控制者和规范文档之类的规范，其定义与上述OAuth 访问令牌类型注册表部分相同，但以下规范除外：

• 错误名称 - 它是请求的名称。

• 错误使用位置 - 它指定错误的位置，例如授权码授予错误响应、隐式授予响应或令牌错误响应等，指定错误可以使用的位置。

• 相关协议扩展 - 可以使用协议扩展，例如扩展授权类型、访问令牌类型、扩展参数等。