一. RFC解读
- 官方rfc: https://tools.ietf.org/html/rfc6749
前言:
authorization:授权(v.), 重点在"赋予"这个动作, 行为主体是服务器，重点也在服务器方,即服务器给予某人xxx
authenticate: 认证(v.), 重点在"证明"这个动作, 行为主体也是服务器, 但重点是客户方,即客户方被验证.
grant: 授予的权利(n.), 重点在被赋予的那个东东本身, 行为主体是服务器+客户端, 这个"权利"从服务器方来，被赋予给了客户方. 至于我们常说的授权, 完整的就是表达就是authorization grant.
注: 所谓客户端,服务端是相对而言...
目录&摘要:
1.协议的整体介绍
1.1 协议中划分了4种角色:
resource owner, resource server, client, authorization server
1.2 协议制定的基本流程(Flow)
1.3 协议核心步骤：权限授予, 包含4种授权方式:
Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials
2.协议的前提:客户端注册
2.1 客户端类型：
从安全的角度划分: confidential, public
从app实现方式划分: web application, user-agent-based application, native application
2.2 客户端身份信息
2.3 客户端认证
3.协议中的端点(从访问的api维度来说明)
4.详解授权码类型的整个流程
1.协议介绍
1.1.角色定义(Roles)
OAuth定义了四种角色
- resource owner
资源所有者.一个可以去授予访问受保护资源(protected resource)的实体, 当着个owner是一个自然人时，它被称作是一个终端用户(end-user)
比如, github上某个的代码的所有者，即me！。
- resource server
资源服务器.托管受保护资源的服务器，能够接收并响应使用访问令牌(access tokens)访问受保护资源(protected resource)的请求
比如, github, 当有请求携带token想要clone代码时, github可以处理这个请求
- client
客户端.一个可以代表resource owner并能构造访问受保护资源(protected resource)请求的应用.
"client"这个术语并没有确定的特征，即这个应用是否运行在服务器上, 还是桌面或者其他设备上都可能。
比如, 某个想要拉取我github上代码的一个应用
- authorization server
授权服务器.一个用来给client签发访问令牌(access tokens)的服务器，当然是指在对resource owner认证成功进而取得了授权之后。
例如, github的授权服务器(https://github.com/settings/applications/new), 访问这个服务器后会让我输入账号(认证), 以及询问我是否允许某个client具备clone权限。
注: 至于resource server和authorization server之间的交互不是本协议所定义的，二者可以是同一个当然也可以是不同的服务器，例如，github, 至少在我们看来二者是一个地址提供的...
1.2 协议的基本流程(Protocol Flow)
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
(A) client请求Resource Owner给它授权, 可以如上图所示向Resource Owner直接请求授权，
但更推荐的是间接通过authorization server获得授权(后面会详细说)
(B) client得到授权(authorization grant)，即拿到了一个能代表resource owner权利的凭证, 本文定义了四种授权类型,
也可以是扩展授权类型。具体哪种类型取决于client想要的以及授权服务器所能提供的。
(C) client拿着授权(grant)去authorization server请求访问令牌.
(D) 授权服务器对client进行身份验证(authenticates)并校验其权限(validates the authorization grant)，
如果有效，则颁发access token。
(E) client携带access token去resource server那里请求protected resource, 后者服务器会通过access token进行身份验证。
(F) resource server对access token校验后如果判定是有效的，则满足client的请求。
【小小结】:
client在得到owner的授权后，拿着授权凭证去authorization server那里换取token, 最后拿着token去resourceserver访问资源。
1.3. 权限授予(Authorization Grant)
wxy: client说自己得到了owner的授权，但口说无凭，所以需要一个机制让授权成立, 所以本文定义了4种方式.
1.授权码(Authorization Code)
相对于直接从owner那边获取授权, 这种方式是向授权服务器(authorization server)请求一种叫做授权码(authorization code)的授权凭据.
客户端会首先会将owner引导到授权服务器(通过user-agent，定义在 [RFC2616]), 然后再携带着授权码(authorization code)将owner引导回客户端.
在引导owner回到client之前, authorization server会对owner进行认证(authenticates), 然后取得授权资格.
由于owner只能被authorization server认证, 所以owner的credentials永远不会让client获知。
授权码(authorization code)方式具备一些重要的安全方面优势(security benefits),
比如认证client的能力,除了会不透过owner的user-agent而是直接将access token传输给client外, 还有可能将其暴露给其他人, 包括owner.
wxy: 传统的直接从owner那边获得授权不是很安全，因为相当于owner将自己的账号密码直接给了client，
但是有了authorization server后，由他来负责和owner和client分别单线打交道:
首先, authorization server和owner对话, 判断owner是否同意授权
然后, authorization server和client打交道, 同意授权则颁发一个授权码给client
这个授权码是authorization server颁发的，所以client自然可以拿着这个码去authorization server那边得到认证
2.隐式授权(Implicit)
是简化版的授权码方式. 此时的client由浏览器中的脚本语言比如js来实现。不同于前者给client颁发的是授权码,
在这种授权交互里是直接给client颁发access token(作为owner的授权结果).
所以说这种授权是隐式的，因为中间凭据(比如授权码)的生成以及使用这种凭据获取access token的过程都没有。
在这种隐式授权方式下, authorization server不需要对client进行认证就会颁发access token. 在某些情况下,
可以通过验证用于发送access token的重定向URI来实现对client的身份认证(verified via the redirection URI
used to deliver the access token to the client).另外, access token可能会暴露给owner或其他具有访问owner's user-agent权限的应用。
隐式授权方式提高了某些client(比如那些in-browser方式实现的应用)的响应能力和效率, 因为他减少了获取access token所需的交互次数.
然而, 这种便利性的代价就是增加了安全的风险, 见10.3和10.6章节...
wxy: 客户端去授权服务器那边获取的直接就是access token, 这个过程可以用如下的流程来描述：
client将owner引导到授权服务器侧, owner输入账号密码后，client直接得到access token.
关于, 对client的认证, 一般是不需要的，但有的时候可以校验redirect URI, 因为这个URI一般就是client的地址。
3.资源owner的密码凭据(Resource Owner Password Credentials)
资源owner的password凭据(比如账号和密码), 可以直接作为认证授权来获得access token.
该凭证仅用在owner和client之间有较高信任度的情况下(例如，client是设备操作系统的一部分，或者是高特权客户端应用)，
或者其他授权类型不是可用(例如授权码)的情况下。
4.client的凭据(Client Credentials)
当protected resources是受client控制, 或者事先已安排受authorization server所保护时, 客户端凭据(或其他形式的客户端身份验证)可以用来作为授权.
通常，当client在行使自己的权利(此时也可将其看做是resource owner)或者基于一个之前与授权服务器应景建立好的授权关系，
一个client credential会被用做一个授予的权限(an authorization grant)。
【小小结】:
Authorization Code:
client领着owner去authorization server获取code, 然后client拿着code获取access token.
Implicit:
client领着owner去authorization server直接获取access token.
Resource Owner Password Credentials:
client拿着owner的凭据去获取access token
Client Credentials:
client拿着自己的凭据去获取access token
2.客户注册(Client Registration)
在启动协议交互之前, client需要先去authorization server那里进行注册.
所谓的客户注册并不需要授权服务器(authorization server)与客户端(client)之间进行直接交互。
When supported by the授权服务器，注册可以依靠其他方式建立信任并获得所需的客户端属性(比如重定向URI，客户端类型).
例如， 注册可以通过使用自签发(self-issued)或第三方签发(third-party-issued)的断言(assertion)来完成，
或由授权服务器通过使用一个受信任的channel来扮演一个客户端发现的角色。
在进行客户端注册时，客户端开发人员应提供如下的信息：
o 客户端类型(client type), 详见2.1
wxy:即表明自己是"注重隐式保护的人"还是"随随便便"的人
o 客户端的重定向URI，详见3.1.2
o 包括授权服务器所需的任何其他信息(例如，应用程序名称，网站，说明，徽标图片，接受法律条款）
2.1 客户端类型(Client Type)
OAuth根据它们与授权服务器进行安全地身份认证的能力(即维护其客户凭证的机密性), 定义了两种客户端类型：
- confidential, 机密型
这种类型的client有能力维护自己的credential的机密性(比如一个实现于安全服务器上的客户端, 其会限制对自己credential的访问),
或者使用其他途径反正要能够安全地进行身份认证的客户端
wxy: 这里暂且存留一个疑问，这个credential是什么意思，是指client自己的凭据还是指授权服务器办法的授权code?
抑或是一个广义的词汇, 代表了所有"凭据"类信息, 包括code, access token等...
- public, 公共型
...
为客户端划分类型是基于授权服务器对安全认证的定义和其所能接受的暴露client credential的级别,而授权服务器自身是不应该去假设客户端的类型
wxy: 意思是说客户端自己的类型的定义有client自己定义, 授权服务器只需要知道如果客户端声称自己的是机密的，那么授权服务器要谨慎对待。
本文档会围绕如下的客户端的配置户或者说是从应用的角度划分的客户端类型：
- 客户端应用(web application)
是指运行在web服务器上的confidential client。html用户接口呈现在资源owner所使用设备的user-agent上, 进而owner 通过这个接口得以访问客户端。
而客户端的credential连同签发给他的access token都会被存放在web服务器上，并不会暴露给owner，owner也没办法主动获取。
wxy:这个是我们最典型的使用场景：
我们自己开发web应用, 比如一个ui/dashboard等运行在web服务器上
首先, 访问web应用的url/api会获取一个html页面显示在浏览器中,
然后, 得到的客户端credential包括access token都会被存放在client自己的应用中
- 基于user-agent的应用(user-agent-based application)
这是一种公共的客户端, 其运行代码是从web服务器上下载下来然后运行在user-agent(比如浏览器)上.
协议数据和credential对owner来说可以很容易获得(通常也是直接可见的). 而由于这样的应用驻留在user-agent中，
所以他们可以在请求授权时无缝使用的user-agent的功能。
wxy:这应该是另一个非常典型的使用场景,
和web应用类似，只不是和授权服务器的交互过程直接在浏览器上完成，通常是web服务器提供给浏览器一分js源码
此时这个js源码就是作为一个client, 他在浏览器上直接和authorizationserver交互,
那么协议交互数据和获取的凭证(比如code,access token)则直接就在浏览器上完成, 也所以谁都看得见.
- 本地应用(native application)
这种本地应用是一种安装并运行在资源owner所使用设备上的public client.协议数据和credential对owner来说可以访问获得.
一般这种情况下, 应用中包含的任何客户端授权credential都是可以提取出来的。
另一方面, 对于动态签发的credential比如access token或者refresh tokent, 是可以接收一个可接受的保护等级.
至少，要保证这些凭据不会被与应用交互的恶意服务器攻击。另外在某些平台上，这些凭据同样也需要免受位于同一设备上的应用程序的攻击。
2.2 客户端id(Client Identifier)
授权服务器给前来注册的客户端颁发了一个客户端标识符(client id) -- 一个用来代表client所提供的注册信息的唯一字符串。
客户端标识符不是密文; 它会暴露给资源所有者，但是不允许仅使用它来进行client授权。该id对授权服务器来说，是唯一的。
客户端标识符字符串的大小本文不做要求, 所以客户应避免对标识符大小做校验。授权服务器应该将其颁发的id大小形成文本方便使用者阅读。
wxy: 首先要明确，这个id是由授权服务器颁发的，用来指代来注册的客户端，确切的说是用来标识客户端提供的一坨注册信息(当然也包括客户端的url等),
2.3 客户认证(Client Authentication)
如果客户端为机密类型的(confidential client), 则客户端和授权服务器需要建立一个认证机制才能满足授权服务器的安全性要求。
授权服务器可以接受任何形式的客户端身份验证同时满足他的安全要求。
机密类型客户端通常会发布(或建立)一组客户端凭据, 用于和授权服务器进行身份认证(例如，密码，公钥/私钥对)。
授权服务器也可以与公共客户(public client)建立客户端认证方法。但是，授权服务器不得将此用于识别(identifying)客户。
客户端在每个请求中不得使用超过一种身份验证方法。
wxy: 这个针对客户的认证是一个广义的要求, 即要求授权服务器对发起请求的client进行认证，包括协议flow的各个阶段都适用,
只要是授权服务器的要求...，这里面的授权服务器(authorization
server)也是广义的, 见下面的两种终端(endpoint)
2.4. 未注册客户端(Unregistered Clients)
本规范不排除使用未注册的客户端。但是，使用此类客户端超出了此范围规范，并需要进行额外的安全分析和审查它的互操作性影响
wxy: 客户端具体如何注册并不是协议的一部分, 这个动作是为了让授权服务器中提前就有client的身份信息,如此就可以更加安全的进行授权操作.
所以，只要满足rfc的要求: client需要提前在server端进行注册，那么具体如何实现则不要求。
3. 协议终端(Protocol Endpoints)
在整个协议制定的交互中, 使用了2个授权服务终端和1个客户终端, 如下：
1. 2个授权服务终端(提供HTTP资源):
o 授权终端(Authorization endpoint) - 用于客户端通过user-agent的重定向来从资源owner那边获取授权.
(used by the client to obtain authorization from the resource owner via user-agent redirection.)
o Token终端(Token endpoint) - 用于客户端使用所授予的权限来交换得到access token, 通常使用客户端认证.
2. 一个客户终端(client endpoint):
o 重定向终端(Redirection endpoint) - 授权服务器通过owner的user-agent, 向这个其回复含有授权凭据的应答.
(used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.)
不是所有权限授予都使用这两部分终端, 当然对于扩展权限类型还可能根据需要定义额外的endpoints
wxy: 所谓endpoints, 其实可以理解成一个地址/api/路由(对应的目的地), 开发过http应用的人都知道, 都有一颗路由树, 每条路由对应一个api, 一个功能handler,
所以, 在这种体系下, endpoint即终端, 正是体现了一种不同的"目的地"的概念, 在本协议中, 典型的包含了三个地址
3.1 Authorization Endpoint
授权端点用于与资源owner进行交互, 并取得owner的授权。授权服务器必须首先验证资源owner的身份。
具体使用什么方式则不规定, 可以是用户名和密码登录，可以是会话cookie.
至于客户如何知道授权端点或者说是授权服务器的url, 则不归本rfc管,但典型的方式是在服务文档中提供.
The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted query component,
which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component.
由于对授权端点的请求导致用户身份验证和明文凭证的传输(在HTTP响应里)，所以授权服务器必须要求在向本服务器发送请求时使用TLS
授权服务器必须支持HTTP "GET"方法, 也可以支持"POST"方法。
不带值发送的参数必须被视为从请求中省略。授权服务器必须忽略无法识别的请求参数。请求和响应参数不得超过一次。
3.1.1 关于应答的类型
授权端点是用在授权码(authorization code)和隐式授权(implicit grant)这两种形式中.
客户端会通过response_type这个字段来告知授权服务器其希望使用的grant类型。
response_type: 必选字段, 如果是授权码类型, 则取值"code", 如4.1.1节; 如果是获取access token(隐式授权类型), 则取值"token", 如4.2.1节;
也可以是一个已经注册了的扩展类型值, 详见第8.4节所述.
扩展响应类型, 是一个由空格(％x20)分隔的列表值，值的顺序无关紧要(例如"a b"与"b a"相同)。至于这种复合响应类型的含义, 则由其各自的规范定义。
如果授权请求中缺少"response_type"参数, 或者是无法识别的类型值，则授权服务器必须返回一个错误应答，如第4.1.2.1节所述。
3.1.2. 关于重定向端点(Redirection Endpoint)
在完成与资源owner的交互后, 授权服务器会将owner的user-agent引导回客户端，使用的就是这个重定向地址(客户端的redirection endpoint),
而该地址是于之前客户端与授权服务器处理注册流程或授权流程时建立的。
重定向端点URI必须是一个绝对URI, 详细见4.3节中的定义。端点URI可以包含一个"application/x-www-form-urlencoded"格式...
针对这个URI有如下的要求：
1. 端点请求的机密性的要求(Endpoint Request Confidentiality)
要求使用tls....
2. 哪些需要进行注册(Registration Requirements)
授权服务器必须要求如下种类的客户端注册其重定向URI：
o 公共客户端.
o 使用隐式授予类型的机密客户端.
授权服务器应该要求所有客户端先注册其重定向端点，然后再使用授权端点。
授权服务器应该要求客户端提供完整的重定向URI(客户端可以使用"state"请求参数以实现每个请求的自定义)。如果无法注册完整的重定向URI,
授权服务器应该要求注册URI的scheme, authority, and path (如此可以允许客户端在请求授权时, 动态变化查询语句).
授权服务器可以允许客户端注册多个重定向端点。
缺少重定向URI可能导致通过将授权端点作为开放重定向器而产生的攻击，详见10.15节中描述。
3. 端点的内容(Endpoint Content)
重定向到客户端端点的请求通常会得到一个HTML文本响应, 然后由user-agent来处理。
所以如果HTML响应直接作为重定向请求的结果, 那么HTML文本中包含的所有脚本都将完整执行,且完全有权限访问重定向URI及其包含的凭据。
客户端不应在重定向端点响应(redirection endpoint response)中包含任何第三方脚本(例如，第三方分析，社交插件，广告网络)。
相反, 它应该从URI中提取凭证, 然后在没有暴露credential的情况下将user-agent再次重定向到另一个端点(URI中或其他地方指定的)。
如果有第三方脚本包含在内，客户端必须确保其自己的脚本(用于从URI中提 取和删除凭据)会先执行。
wxy: 所谓重定向, 即授权服务器带着凭证信息访问之前指定的Redirection url交给浏览器
(这是一个特殊的http应答么? 一个来自授权服务器给浏览器的?)
所以, 当浏览器访问这个重定向url也即向client发出请求后, 会得到client返回的应答，通常是一个html网页, 由user-agent即浏览器负责处理处理。
需要注意的是，client收到请求后应该第一时间提取给自己的credential, 同时返回的这个html应答中不能包括脚本程序.
3.2. 令牌端点(Token Endpoint)
客户端通过向token endpoint提供授权grant或refresh token, 进而获取access token。
token endpoint需要与所有授权grant一起使用，除了隐式授权类型(因为直接颁发了access token)。
至于客户端是如何获取token endpoint的地址则不在本文档的讨论范围中, 通常这个地址会由服务文档提供。
endpoint的urI可以包含"application/x-www-form-urlencoded"....
由于对token endpoint的请求会导致明文credential的传输(在http请求和应答中), 所以授权服务器必须要使用tls...
客户端必须要使用POST方法去请求access token
请求中如果携带了没有值的参数, 则应该被忽略, 同时必须忽略无法识别的请求参数。请求和响应参数不得重复。
3.2.1 客户端的认证(Client Authentication)
在2.3章节中已经说过, 机密型客户端或其他类型客户端在向令牌端点发出请求时，
其使用的客户凭据必须经由授权服务器进行身份认证才行。这么做的原因是:
o 强制将refresh token和授权码绑定到所签发给的客户端上
。对于当授权码会通过一个不安全的通道传输到重定向 endpoint,
或重定向URI具有尚未完全注册时, 客户端身份验证显得至关重要。
o 可以通过禁用客户端或更改其凭据, 来恢复受感染的客户端，
从而防止攻击者滥用盗取的refresh token。
更改一组客户凭证比吊销一整套refresh token要快得多。
o 实施身份认证管理的最佳实践是，定期的凭证轮换。
整套轮换机制可能使得设置refresh token, 刷新令牌可能具有挑战性，而单组的凭证轮换机制则会非常容易。
客户端在向token endpoint发送请求时，可以使用"client_id"参数来标识自己。在发向token endpoint的
"authorization_code""grant_type"请求中, 一个未经身份验证的客户端必须发送其"client_id",
这样可以避免不小心接收了本来是签发给其他具有不同"client_id"的客户端的授权码。(针对受保护资源并没有提供额外的保护机制)。
3.3 访问token的使用范围(Access Token Scope)
authorization 和 token endpoints允许客户端通过使用"scope"参数来指定访问请求的范围。
再然后，授权服务器通过使用"scope"响应参数来通知客户端其颁发的access token的范围。
scope参数的值使用一个以空格为分隔符的字符串列表表达式,区分大小写的。字符串由授权服务器定义。
如果值包含多个以空格分隔的字符串，它们的顺序无关紧要，并且每个字符串都会添加一个所请求范围的其他访问范围。
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
...
小结
从http请求应答的维度，将整个协议的交互串联起来: 三个endpoint的交互
首先，客户端端请求Authorization endpoint/url获取授权，
然后, 假设同意授权, 授权服务器将grant凭据以及client endpoint/url交给浏览器让其重定向访问该url, 进而客户端取得grant
最后，客户端请求Token endpoint/url换取access token
---请求with redirect uri---> Authorization endpoint
<----应答 and redirect-----
浏览器
------------请求---------> Redirection endpoint
<----------应答---------- /client <------------------> Token endpoint
一般, 授权服务器Authorization Server是广义的, 其提供了2种功能, 于是对应2个路由/api/endpoint.
对于重定向URI, 是client在向授权服务器注册的时候提供给他的，用来在授权服务器生成credential(包括授权码，access token等)后，知道将些凭证交给谁,
通常是借助user-agent携带credential信息重定向访问该URI, 而作为credential的接收者同时作为一次http请求的服务方，还要给user-agent(浏览器)一个应答,
那么这个应答一定要把凭证信息剥离下来....
4.获得授权(Obtaining Authorization)
4.1授权码方式详解(Authorization Code Grant)
授权码方式包括获取access token和refresh token, 同时对受信任客户端进行了优化。
于这是一套基于重定向的流程，因此客户端必须具备与资源owner的user-agent(通常是是web浏览器)进行交互的能力,
还要具备接收来自authorization server的进向请求(通过重定向的方式).
完整流程如下：
注意：用来描述步骤(A)(B)(C)的三条线由于涉及到user-agent所以被分隔成2个part
二. 一实际应用场景
一个web应用(web application类型的client),
需要能够拉取某个用户(resource owner)在github上(authorization server)的代码(protected resource).
结合实际场景的流程解析：
(A) 整个流程始于客户端将资源owner的user-agent引导到授权端点开始，客户端会提供它的client id, scope, local state和redirection URI,
其中redirection URI表示一旦授权通过(或拒绝), 则授权服务器会将user-agent发送到这个地址上(重定向到这个地址上).
wxy: 根据图示可知, A步骤分两个part: client --引导--> user-agent;
user-agent --访问--> Authorization server;
实际场景: 首先, 这个web应用呈现在浏览器上的页面中已经集成了要发送给a s的关键信息(client id等),
然后, 一旦特定操作触发，页面上的js(或其他方式)会让浏览器直接向github的地址发出请求
请求中会携带client id, scope, local state和redirection URI,等
(B) 授权服务器会对资源owner进行身份验证(通过user-agent), 并确定owner是允许还是拒绝客户端的访问请求。
实际场景: github会返回授权页面给浏览器, 提示owner输入账号密码等信息
(C) 假设资源owner授予了访问权限, 则授权服务器使用之前提供的重定向URI(可以是本次请求的时或是客户端注册时)
将user-agent重定向回客户端. 重定向URI包含一个授权代码和客户端提供的任何本地状态较早。
wxy: 根据前面知道, 客户端注册的时候也会提供重定向uri, 同样要求向as发授权请求还是要携带redirection URI,
当然，这中间client id是一个client唯一的身份标识。
最后，浏览器会拼接as返回的授权码到redirection uri上来访问这个地址
实际场景: 首先, as为client生成了授权码:code, 然后带着redirection uri(即client的某个api)告诉浏览器该重定向了
于是, 浏览器带着code访问client
(D) 客户端携带上一步中获得的授权码, 去授权服务器的令牌端点(token endpoint)请求access token.
在请求中, 授权服务器会对客户端进行认证, 而客户端为了认证通过也会将用于获得授权码的重定向URI也包含进来。
实际场景: 我的应用拿着code 和 redirection uri访问github的token api
(E) 授权服务器对客户端进行身份验证，校验授权码，并确保本次接收的重定向URI与步骤(C)中接收的匹配。
如果一切验证通过, 则授权服务器将回复access token, 可选的还有refresh token.
实际场景: github进过一些列验证, 返回给我的应用一个token.
wxy: 如上的流程实际上是省略了注册的环节，因为只有注册了才会得到一个client id, 另外虽然本文档中并没有明确说明在发出授权请求的时候，
会验证携带的redirect URI, 但是结合一个开源的实现，加上常规理解，必然应该对授权请求中携带的redirect URI进行校验，只有符合注册时的才可以，
毕竟二者使用的是相同的client id.