为了请求访问令牌，客户端从资源所有者获得授权。授权表现为授权许可的形式，客户端用它请求访问令牌。OAuth定义了四种许可类型：授权码、隐式许可、资源所有者密码凭据和客户端凭据。它还提供了扩展机制定义其他许可类型。

4.1. 授权码许可

4.1.1. 授权请求

4.1.2. 授权响应

4.1.3. 访问令牌请求

4.1.4. 访问令牌响应

4.1. 授权码许可

授权码许可类型用于获得访问令牌和刷新令牌并且为受信任的客户端进行了优化。由于这是一个基于重定向的流程，客户端必须能够与资源所有者的用户代理（通常是Web浏览器）进行交互并能够接收来自授权服务器的传入请求（通过重定向）。

 +----------+| Resource ||   Owner  ||          |+----------+^|(B)+----|-----+          Client Identifier      +---------------+|         -+----(A)-- & Redirection URI ---->|               ||  User-   |                                 | Authorization ||  Agent  -+----(B)-- User authenticates --->|     Server    ||          |                                 |               ||         -+----(C)-- Authorization Code ---<|               |+-|----|---+                                 +---------------+|    |                                         ^      v(A)  (C)                                        |      ||    |                                         |      |^    v                                         |      |+---------+                                      |      ||         |>---(D)-- Authorization Code ---------'      ||  Client |          & Redirection URI                  ||         |                                             ||         |<---(E)----- Access Token -------------------'+---------+       (w/ Optional Refresh Token)

注：说明步骤（A）、（B）和（C）的直线因为通过用户代理而被分为两部分。
图3：授权码流程

在图3中所示的流程包括以下步骤：

（A）客户端通过向授权端点引导资源所有者的用户代理开始流程。客户端包括它的客户端标识、请求范围、本地状态和重定向URI，一旦访问被许可（或拒绝）授权服务器将传送用户代理回到该URI。
（B）授权服务器验证资源拥有者的身份（通过用户代理），并确定资源所有者是否授予或拒绝客户端的访问请求。
（C）假设资源所有者许可访问，授权服务器使用之前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端。重定向URI包括授权码和之前客户端提供的任何本地状态。
（D）客户端通过包含上一步中收到的授权码从授权服务器的令牌端点请求访问令牌。当发起请求时，客户端与授权服务器进行身份验证。客户端包含用于获得授权码的重定向URI来用于验证。
（E）授权服务器对客户端进行身份验证，验证授权代码，并确保接收的重定向URI与在步骤（C）中用于重定向（资源所有者的用户代理）到客户端的URI相匹配。如果通过，授权服务器响应返回访问令牌与可选的刷新令牌。

4.1.1. 授权请求

客户端通过按附录B使用“application/x-www-form-urlencoded”格式向授权端点URI的查询部分添加下列参数构造请求URI：

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

客户端使用HTTP重定向响应向构造的URI定向资源所有者，或者通过经由用户代理至该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定向用户代理，或者通过经由用户代理至该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.3. 访问令牌请求

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

grant_type
必需的。值必须被设置为“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中，它可能会暴露给资源所有者和其他驻留在相同设备上的应用。

 +----------+| Resource ||  Owner   ||          |+----------+^|(B)+----|-----+          Client Identifier     +---------------+|         -+----(A)-- & Redirection URI --->|               ||  User-   |                                | Authorization ||  Agent  -|----(B)-- User authenticates -->|     Server    ||          |                                |               ||          |<---(C)--- Redirection URI ----<|               ||          |          with Access Token     +---------------+|          |            in Fragment|          |                                +---------------+|          |----(D)--- Redirection URI ---->|   Web-Hosted  ||          |          without Fragment      |     Client    ||          |                                |    Resource   ||     (F)  |<---(E)------- Script ---------<|               ||          |                                +---------------++-|--------+|    |(A)  (G) Access Token|    |^    v+---------+|         ||  Client ||         |+---------+

注：说明步骤（A）和（B）的直线因为通过用户代理而被分为两部分。

图4：隐式许可流程

图4中的所示流程包含以下步骤：

（A）客户端通过向授权端点引导资源所有者的用户代理开始流程。客户端包括它的客户端标识、请求范围、本地状态和重定向URI，一旦访问被许可（或拒绝）授权服务器将传送用户代理回到该URI。
（B）授权服务器验证资源拥有者的身份（通过用户代理），并确定资源所有者是否授予或拒绝客户端的访问请求。
（C）假设资源所有者许可访问，授权服务器使用之前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端。重定向URI在URI片段中包含访问令牌。
（D）用户代理顺着重定向指示向Web托管的客户端资源发起请求（按RFC2616该请求不包含片段）。用户代理在本地保留片段信息。
（E）Web托管的客户端资源返回一个网页（通常是带有嵌入式脚本的HTML文档），该网页能够访问包含用户代理保留的片段的完整重定向URI并提取包含在片段中的访问令牌（和其他参数）。
（F）用户代理在本地执行Web托管的客户端资源提供的提取访问令牌的脚本。
（G）用户代理传送访问令牌给客户端。

参见1.3.2节和第9节了解使用隐式许可的背景。

参见10.3节和10.16节了解当使用隐式许可时的重要安全注意事项。

第四章 OAuth2.0规范（史上最详细解释）——获得授权相关推荐

螺旋矩阵【史上最详细解释】
解题思路:\ 观察一下,螺旋数组其实是按圈走的,每一个圈的起始点都在对角线上(matrix[i][i]),但是一共有几个圈的起始点呢?如果是nn的那么就有n//2个起始点,如果是mn的那就是min(m ...
ACPI Specification 第四章 ACPI硬件规范
第四章 ACPI硬件规范... 2 4.1 Hardware-Reduced ACPI 3 4.1.1 Hardware-Reduced事件... 3 4.1.1.1 GPIO提示事件或中断提示事件. ...
史上最详细的Android Studio系列教程四--Gradle基础
史上最详细的Android Studio系列教程四--Gradle基础转载于:https://www.cnblogs.com/zhujiabin/p/5125917.html
史上最详细的Pytorch版yolov3代码中文注释详解（四）
史上最详细的Pytorch版yolov3代码中文注释详解(一):https://blog.csdn.net/qq_34199326/article/details/84072505 史上最详细的Pyt ...
现实迷途第三十四章响亮一巴（上）
第三十四章响亮一巴(上) 注:原创作品,请尊重原作者,未经同意,请勿转载,否则追究责任. 钟琳的出现,不免让江北的心思发生了一点点的变化,给他和钱珊之间的关系带来了一点额外的想象空间,但也只是限于一 ...
史上最详细全中文 Cisco 3560交换机使用手册
史上最详细全中文 Cisco 3560交换机使用手册 (末尾送交换机安全技术) 目录 CISCO Catalyst 3560-E系列交换机的功能应用及安全解决方案 3 一.Cisco? Cataly ...
史上最详细网络基础知识
网络技术的基本原理: 1. 网络层次划分 2. OSI七层网络模型 3. IP地址 4. 子网掩码及网络划分 5. ARP/RARP协议 6. 路由选择协议 7. TCP/IP协议 8. UDP协议 ...
史上最详细的MySQL操作事例
史上最详细的MySQL操作事例文章目录史上最详细的MySQL操作事例一.数据库的操作二.数据表的操作三.数据表的增删查该四.数据准备五.条件查询六.排序七.聚合函数八.分组九.分 ...
IPV4与IPV6的区别（史上最详细）
IPV4与IPV6的区别(史上最详细) 描述 IPv4 IPv6 地址长度为 32 位(4 个字节).地址由网络和主机部分组成,这取决于地址类.根据地址的前几位,可定义各种地址类:A.B.C.D 或 ...

第四章 OAuth2.0规范（史上最详细解释）——获得授权

4.1. 授权码许可

4.1.1. 授权请求

4.1.2. 授权响应

4.1.3. 访问令牌请求

4.1.4. 访问令牌响应

4.2. 隐式许可

第四章 OAuth2.0规范（史上最详细解释）——获得授权相关推荐

最新文章

热门文章