OAuth 2.0 - 快速指南
OAuth 2.0 - Overview
什么是OAuth 2.0？
OAuth是一种开放式授权协议，允许通过在Facebook，GitHub等HTTP服务上启用客户端应用程序来访问资源所有者的资源。它允许将存储在一个站点上的资源共享到另一个站点，而无需使用其凭据。 它使用用户名和密码令牌代替。
OAuth 2.0由IETF OAuth Working Group ，于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 - Architecture
在本章中，我们将讨论OAuth 2.0的架构风格。
Step 1 - 首先，用户使用诸如Google，Facebook，Twitter等客户端应用程序访问资源。
Step 2 - 接下来，在注册重定向URI（统一资源标识符）期间，将向客户端应用程序提供客户端ID和客户端密码。
Step 3 - 用户使用身份验证应用程序登录。 客户端ID和客户端密码对授权服务器上的客户端应用程序是唯一的。
Step 4 - 验证服务器使用授权代码将用户重定向到重定向统一资源标识符（URI）。
Step 5 - 用户访问位于客户端应用程序中的重定向URI的页面。
Step 6 - 将向客户端应用程序提供身份验证代码，客户端ID和客户端密码，并将其发送到授权服务器。
Step 7 - 身份验证应用程序将访问令牌返回给客户端应用程序。
Step 8 - 一旦客户端应用程序获得访问令牌，用户就开始使用客户端应用程序访问资源所有者的资源。
OAuth 2.0有各种概念，下表对这些概念进行了简要说明。
| Sr.No. | 概念与描述 |
|---|---|
| 1 | Terminology OAuth提供了一些额外的术语来理解授权的概念。 |
| 2 | Web Server Web服务器提供Web页面并使用HTTP向用户提供构成Web页面的文件。 |
| 3 | User-Agent 用户代理应用程序由用户设备中的客户端应用程序使用，该用户设备充当脚本语言实例。 |
| 4 | Native Application 本机应用程序可用作桌面或移动电话应用程序的实例，该应用程序使用资源所有者密码凭据。 |
OAuth 2.0 - Client Credentials
当客户端是资源所有者时，或者当授权范围限于受客户端控制的受保护资源时，客户端凭证可以用作授权授权。
客户端仅在客户端凭据的帮助下请求访问令牌。
客户端凭证授权流用于获取访问令牌以授权API请求。
使用客户端凭据授权，获取的访问令牌仅授予客户端应用程序搜索和获取目录文档的权限。
下图描绘了客户端凭据流。
上图所示的流程包括以下步骤 -
Step 1 - 客户端使用授权服务器进行身份验证，并从令牌端点发出访问令牌请求。
Step 2 - 授权服务器对客户端进行身份验证，并在访问令牌有效和授权时提供访问令牌。
下表列出了客户端凭据的概念。
| Sr.No. | 概念与描述 |
|---|---|
| 1 | Obtaining End-User Authorization 授权端点通常是授权服务器上的URI，资源所有者在其中登录并允许访问客户端应用程序的数据。 |
| 2 | Authorization Response 授权响应可用于获取访问令牌，以使用授权代码访问系统中的所有者资源。 |
| 3 | Error Response and Codes 如果在授权期间发生错误，授权服务器将使用HTTP 400或401（错误请求）状态代码进行响应。 |
OAuth 2.0 - Obtaining an Access Token
访问令牌是标识用户，应用程序或页面的字符串。 令牌包括诸如令牌何时到期以及哪个应用创建该令牌的信息。
首先，有必要从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 - 它可以是代码或令牌。 代码必须用于服务器端应用程序，而令牌必须用于客户端应用程序。 在服务器端应用程序中，您可以确保安全地保存机密。
下表列出了客户端凭据的概念。
| Sr.No. | 概念与描述 |
|---|---|
| 1 | Authorization Code 授权代码允许访问授权请求并授予对客户端应用程序的访问权以获取所有者资源。 |
| 2 | Resource Owner Password Credentials 资源所有者密码凭据仅包含一个请求和一个响应，并且在资源所有者与客户端具有良好关系的情况下非常有用。 |
| 3 | Assertion 断言是一组信息，可以跨各种安全域共享身份和安全信息。 |
| 4 | Refresh Token 刷新令牌用于获取新的访问令牌，其携带获取新访问令牌所需的信息。 |
| 5 | Access Token Response 访问令牌是授权服务器分配的一种令牌。 |
| 6 | 访问令牌错误响应代码 如果授权服务器发出的令牌访问请求无效或未授权，则授权服务器返回错误响应。 |
OAuth 2.0 - Accessing a Protected Resource
客户端向资源服务器提供访问令牌以访问受保护资源。 资源服务器必须验证并验证访问令牌是否有效且未过期。
发送凭据有两种标准方式 -
Bearer Token - 访问令牌只能作为授权HTTP头中的后备选项放在POST请求正文或GET URL参数中。
它们包含在授权标题中，如下所示 -
Authorization: Bearer [token-value]
例如 -
GET/resource/1 HTTP /1.1
Host: example.com
Authorization: Bearer abc...
MAC - 使用请求的元素计算加密Message Authentication Code （MAC）并将其发送到授权头。 在接收到请求之后，然后由资源所有者比较并计算MAC。
下表显示了访问受保护资源的概念。
| Sr.No. | 概念与描述 |
|---|---|
| 1 | 经过身份验证的请求 它用于获取授权代码令牌以访问系统中的所有者资源。 |
| 2 | WWW-Authenticate响应标头字段 如果受保护资源请求包含无效访问令牌，则资源服务器包括“WWW-Authenticate”响应头字段。 |
OAuth 2.0 - Extensibility
有两种方法可以定义访问令牌类型 -
通过在访问令牌类型的注册表中注册。
通过使用唯一的绝对URI（统一资源标识符）作为其名称。
定义新的端点参数
参数名称必须遵守参数名称ABNF（Augmented Backus-Naur Form是一种基于Backus-Naur形式的元语言，由其自己的语法和派生规则组成），参数值的语法必须明确定义。
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（增强的Backus-Naur表单），并且在可能的情况下，它应该以标识它的名称作为前缀。
error = 1 * error_char
error-char = %x20-21/%x23-5B/5D-7E
OAuth 2.0 - IANA Considerations
IANA代表I nternet A签名的N umbers A uthority，它提供有关与R emote认证相关的注册值的信息（RADIUS）。
IANA包括以下注意事项 -
OAuth访问令牌类型注册表
OAuth访问令牌由具有所需规范的专家注册。 如果他们对注册感到满意，那么他们才会发布规范。 注册请求将被发送到@ ietf.org以便与主题一起审阅（“请求访问令牌类型:示例”）。 专家将在请求后的14天内拒绝或接受请求。
注册模板
注册模板包含以下规范 -
Type Name - 这是请求的名称。
Token Endpoint Response Parameters - 附加访问令牌响应参数将在OAuth参数注册表中单独注册。
HTTP Authentication Scheme - HTTP身份验证方案可用于通过使用访问令牌对资源进行身份验证。
Change Controller - 为标准轨道RFC提供状态名称“IETF”，对于其他人，请使用责任方的名称。
Specification Document - 规范文档包含可用于检索文档副本的参数。
OAuth参数注册表
OAuth参数注册表包含授权端点请求或响应，令牌端点请求或具有所需规范的专家的响应的注册。 注册请求将发送给专家，如果他们对注册感到满意，那么他们将发布规范。
注册模板
注册模板包含上述OAuth Access Token Types Registry部分中定义的Type Name, Change Controller和Specification Document等Specification Document ，但以下规范除外 -
Parameter Usage Location - 它指定参数的位置，例如授权请求或响应，令牌请求或响应。
初始注册内容
下表显示了包含初始内容的OAuth参数注册表 -
| Sr.No. | 参数名称和使用位置 | 改变控制器 | 规范文件 |
|---|---|---|---|
| 1 | client_id 授权请求，令牌请求 | IETF | RFC 6749 |
| 2 | client_secret 令牌请求 | IETF | RFC 6749 |
| 3 | response_type authorization_request | IETF | RFC 6749 |
| 4 | redirect_uri 授权请求，授权 | IETF | RFC 6749 |
| 5 | scope 授权请求或响应，令牌请求或响应 | IETF | RFC 6749 |
| 6 | state 授权请求或响应 | IETF | RFC 6749 |
| 7 | code 令牌请求，授权响应 | IETF | RFC 6749 |
| 8 | error_description 授权响应，令牌响应 | IETF | RFC 6749 |
| 9 | error_uri 授权响应，令牌响应 | IETF | RFC 6749 |
| 10 | grant_type 令牌请求 | IETF | RFC 6749 |
| 11 | access_token 授权响应，令牌响应 | IETF | RFC 6749 |
| 12 | token_type 授权响应，令牌响应 | IETF | RFC 6749 |
| 13 | expires_in 授权响应，令牌响应 | IETF | RFC 6749 |
| 14 | username 令牌请求 | IETF | RFC 6749 |
| 15 | password 令牌请求 | IETF | RFC 6749 |
| 16 | refresh_token 令牌请求，令牌响应 | IETF | RFC 6749 |
OAuth授权端点响应类型注册表
这可用于定义OAuth授权端点响应类型注册表。 响应类型由具有所需规范的专家注册，如果他们对注册感到满意，则他们将发布规范。 注册申请将发送至@ ietf.org进行审核。 专家将在请求后的14天内拒绝或接受请求。
注册模板
注册模板包含上述OAuth Access Token Types Registry部分中定义的Type Name, Change Controller和Specification Document等Specification Document 。
初始注册内容
下表显示了包含初始内容的授权端点响应类型注册表。
| Sr.No. | 参数名称 | 改变控制器 | 规范文件 |
|---|---|---|---|
| 1 | code | IETF | RFC 6749 |
| 2 | token | IETF | RFC 6749 |
OAuth扩展错误注册表
这可用于定义OAuth Extensions错误注册表。 错误代码以及协议扩展（例如授权类型，令牌类型等）由具有所需规范的专家注册。 如果他们对注册感到满意，那么他们将发布规范。 注册请求将发送到@ ietf.org以便与主题一起审阅（“请求错误代码:示例”）。 专家将在请求后的14天内拒绝或接受请求。
注册模板
注册模板包含上述OAuth Access Token Types Registry部分中定义的Change Controller和Specification Document等Specification Document ，但以下规范除外 -
Error Name - 这是请求的名称。
Error Usage Location - 它指定错误的位置，例如授权代码授予错误响应，隐式授权响应或令牌错误响应等，它指定可以使用错误的位置。
Related Protocol Extension - 您可以使用扩展授权类型，访问令牌类型，扩展参数等协议扩展。
