OAuth 2.0 - 快速指南
OAuth 2.0 - 概述
什么是 OAuth 2.0？
OAuth 是一种开放授权协议，允许通过启用 HTTP 服务（例如 Facebook、GitHub 等）上的客户端应用程序来访问资源所有者的资源。它允许将存储在一个站点上的资源共享到另一个站点，而无需使用其凭据。它使用用户名和密码令牌来代替。
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 有各种概念，下表对其进行了简要解释。
| 先生。 | 概念与描述 |
|---|---|
| 1 | 术语
OAuth 提供了一些附加术语来理解授权的概念。 |
| 2 | 网络服务器
Web 服务器交付网页并使用 HTTP 向用户提供构成网页的文件。 |
| 3 | 用户代理
用户代理应用程序由用户设备中的客户端应用程序使用，充当脚本语言实例。 |
| 4 | 原生应用程序
本机应用程序可以用作桌面或移动电话应用程序的实例，它使用资源所有者密码凭据。 |
OAuth 2.0 - 客户端凭据
当客户端是资源所有者时，或者当授权范围仅限于客户端控制下的受保护资源时，客户端凭据可用作授权授予。
客户端仅在客户端凭据的帮助下请求访问令牌。
客户端凭据授权流程用于获取访问令牌以授权 API 请求。
使用客户端凭据授权，获取的访问令牌仅授予客户端应用程序搜索和获取目录文档的权限。
下图描述了客户端凭据流程。
上图所示的流程包括以下步骤 -
步骤 1 - 客户端向授权服务器进行身份验证，并从令牌端点请求访问令牌。
步骤 2 - 授权服务器对客户端进行身份验证，并提供访问令牌（如果它有效且已授权）。
下表列出了客户端凭据的概念。
| 先生。 | 概念与描述 |
|---|---|
| 1 | 获得最终用户授权
授权端点通常是授权服务器上的 URI，资源所有者在其中登录并允许客户端应用程序访问数据。 |
| 2 | 授权响应
授权响应可用于获取访问令牌，以便使用授权代码访问系统中的所有者资源。 |
| 3 | 错误响应和代码
如果授权期间发生错误，授权服务器会使用 HTTP 400 或 401（错误请求）状态代码进行响应。 |
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 - 它可以是代码或令牌。该代码必须用于服务器端应用程序，而令牌必须用于客户端应用程序。在服务器端应用程序中，您可以确保安全保存机密。
下表列出了客户端凭证的概念。
| 先生。 | 概念与描述 |
|---|---|
| 1 | 授权码
授权代码允许访问授权请求并授予客户端应用程序访问权限以获取所有者资源。 |
| 2 | 资源所有者密码凭证
资源所有者密码凭据仅包含一个请求和一个响应，在资源所有者与客户端关系良好的情况下非常有用。 |
| 3 | 断言
断言是一个信息包，它使得跨不同安全域共享身份和安全信息成为可能。 |
| 4 | 刷新令牌
刷新令牌用于获取新的访问令牌，其中携带获取新的访问令牌所需的信息。 |
| 5 | 访问令牌响应
访问令牌是由授权服务器分配的一种令牌。 |
| 6 | 访问令牌错误响应代码
如果授权服务器发出的令牌访问请求无效或未经授权，则授权服务器返回错误响应。 |
OAuth 2.0 - 访问受保护的资源
客户端向资源服务器提供访问令牌以访问受保护的资源。资源服务器必须验证访问令牌是否有效且未过期。
有两种发送凭据的标准方法 -
Bearer Token - 访问令牌只能放置在 POST 请求正文或 GET URL 参数中，作为授权 HTTP 标头中的后备选项。
它们包含在授权标头中，如下所示 -
Authorization: Bearer [token-value]
例如 -
GET/resource/1 HTTP /1.1 Host: example.com Authorization: Bearer abc...
MAC -使用请求的元素计算加密消息身份验证代码(MAC)，并将其发送到授权标头。收到请求后，资源所有者将比较和计算 MAC。
下表显示了访问受保护资源的概念。
| 先生。 | 概念与描述 |
|---|---|
| 1 | 经过身份验证的请求
用于获取访问系统中所有者资源的授权码令牌。 |
| 2 | WWW-Authenticate 响应标头字段
如果受保护的资源请求包含无效的访问令牌，则资源服务器包括“WWW-Authenticate”响应头字段。 |
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
如果响应类型具有一个或多个空格字符，其中值的顺序无关紧要，并且只能注册一种值顺序，则响应类型将作为以空格分隔的值列表进行比较。
定义附加错误代码
如果扩展错误代码使用的扩展是注册的访问令牌或注册的端点参数，则必须注册扩展错误代码。错误代码必须遵循错误 ABNF（增强巴科斯-诺尔范式），并且在可能的情况下，应以识别它的名称为前缀。
error = 1 * error_char error-char = %x20-21 / %x23-5B / 5D-7E
OAuth 2.0 - IANA 注意事项
IANA 代表互联网号码分配机构，它提供与远程身份验证拨号用户服务( RADIUS)相关的注册值信息。
IANA 包括以下考虑因素 -
OAuth 访问令牌类型注册表
OAuth 访问令牌由专家按照所需规范注册。如果他们对注册感到满意，他们才会发布规范。注册请求将发送到@ietf.org 进行审核，主题为“请求访问令牌类型：示例”。专家将在请求后 14 天内拒绝或接受该请求。
注册模板
注册模板包含以下规范 -
类型名称- 这是请求的名称。
令牌端点响应参数- 附加访问令牌响应参数将在 OAuth 参数注册表中单独注册。
HTTP 身份验证方案- HTTP 身份验证方案可用于通过使用访问令牌来对资源进行身份验证。
更改控制器- 对于标准轨道 RFC，将状态名称指定为“IETF”，对于其他情况，使用责任方的名称。
规范文档- 规范文档包含可用于检索文档副本的参数。
OAuth 参数注册表
OAuth 参数注册表包含由具有所需规范的专家进行的授权端点请求或响应、令牌端点请求或响应的注册。注册请求将发送给专家，如果他们对注册感到满意，那么他们将发布规范。
注册模板
注册模板包含上述OAuth 访问令牌类型注册表部分中定义的类型名称、更改控制器和规范文档等规范，但以下规范除外 -
参数使用位置- 它指定参数的位置，例如授权请求或响应、令牌请求或响应。
初始注册表内容
下表显示了包含初始内容的 OAuth 参数注册表 -
| 先生。 | 参数名称及使用位置 | 变更控制器 | 规格文件 |
|---|---|---|---|
| 1 | 客户ID 授权请求、令牌请求 |
互联网工程任务组 | RFC 6749 |
| 2 | 客户端秘密 令牌请求 |
互联网工程任务组 | RFC 6749 |
| 3 | 响应类型 授权请求 |
互联网工程任务组 | RFC 6749 |
| 4 | 重定向URI 授权请求、授权 |
互联网工程任务组 | RFC 6749 |
| 5 | 范围 授权请求或响应、令牌请求或响应 |
互联网工程任务组 | RFC 6749 |
| 6 | 状态 授权请求或响应 |
互联网工程任务组 | RFC 6749 |
| 7 | 代码 令牌请求、授权响应 |
互联网工程任务组 | RFC 6749 |
| 8 | 错误描述 授权响应、令牌响应 |
互联网工程任务组 | RFC 6749 |
| 9 | 错误_uri 授权响应、令牌响应 |
互联网工程任务组 | RFC 6749 |
| 10 | 授予类型 令牌请求 |
互联网工程任务组 | RFC 6749 |
| 11 | 访问令牌 授权响应、令牌响应 |
互联网工程任务组 | RFC 6749 |
| 12 | 令牌类型 授权响应、令牌响应 |
互联网工程任务组 | RFC 6749 |
| 13 | 过期日期在 授权响应、令牌响应 |
互联网工程任务组 | RFC 6749 |
| 14 | 用户名 令牌请求 |
互联网工程任务组 | RFC 6749 |
| 15 | 密码 令牌请求 |
互联网工程任务组 | RFC 6749 |
| 16 | 刷新令牌 令牌请求、令牌响应 |
互联网工程任务组 | RFC 6749 |
OAuth 授权端点响应类型注册表
这可用于定义 OAuth 授权端点响应类型注册表。响应类型由专家按照所需的规范进行注册，如果他们对注册感到满意，那么他们才会发布规范。注册请求将发送至@ietf.org 进行审核。专家将在请求后 14 天内拒绝或接受请求。
注册模板
注册模板包含上述OAuth 访问令牌类型注册表部分中定义的规范，例如类型名称、更改控制器和规范文档。
初始注册表内容
下表显示了包含初始内容的授权端点响应类型注册表。
OAuth 扩展错误注册表
这可用于定义 OAuth 扩展错误注册表。错误代码以及协议扩展（例如授权类型、令牌类型等）由专家按照所需的规范进行注册。如果他们对注册感到满意，那么他们将发布规范。注册请求将发送至@ietf.org 进行审核，主题为“请求错误代码：示例”。专家将在请求后 14 天内拒绝或接受该请求。
注册模板
注册模板包含上述OAuth 访问令牌类型注册表部分中定义的变更控制器和规范文档等规范，但以下规范除外 -
错误名称- 这是请求的名称。
错误使用位置- 它指定错误的位置，例如授权码授予错误响应、隐式授予响应或令牌错误响应等，它指定可以在哪里使用错误。
相关协议扩展- 您可以使用协议扩展，例如扩展授予类型、访问令牌类型、扩展参数等。