授权流程抽象图

正式开始前还是请大家自行回顾一下小美的案例场景，OAuth 2.0 中的授权码模式就是专为这类使用场景而存在的，授权码模式也是 OAuth 2.0 四种授权模式中步骤最严密，授权过程最严谨的一个授权模式。上图上一篇图文中贴过的抽象授权图，接下来咱们就看一看授权码模式授权的流程图

授权码模式示意图

这里给出的图示只对授权（获取Access Token）的过程进行了“多态化”得扩展，后续其他授权模式的流程图示意图也是对这个过程的不同“多态”表示。很多人看到图基本就🤮了，但是请多给自己打打气，耐下心来学会如何去看懂这些看似非常晦涩的图，这是咱们必须要具备的一项业务能力，而且是一项基本功，是一项值得咱们去掌握的能力，更何况掌握它并不难。在这里又出现了一个新东西：

User Agent - 用户代理，在这里它代指浏览器。 用户代理和图中的 Client 其实是一个系统下的不同组成部分，这个系统在授权场景下就是“客户端”，只不过在这里又把客户端进行了职责功能的分拆，分拆为前端 [User Agent] 和后段[Client] 指的是被授权的第三方应用的后台服务器。接下来咱们看一看它整个授权步骤：

[A] 用户访问客户端，后者将前者导向认证服务器。

[B] 用户选择是否给予客户端授权。

[C] 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

[D] 客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

[E] 认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。 

单看这个简要说明的话，我们并不能真正明白到底怎么一回事，我们可以用我们最熟悉的第三方登录来辅助我们理解授权码模式授权的整个流程，我们已经知道，要想使用第三方登录，第三方的应用或网站必须得到用户和微信的联合授权才能从微信的服务器中拿到用户基本信息，要想让微信认可这个第三方的网站，首先微信得知道有这个网站的存在，而且必须以这个网站的名义向微信开放平台提交一个正式的申请，在微信开发平台进行资格申请时，我们要提供的信息包括网站的基本信息，服务范围，负责人等，然后才是授权相关的开发信息的设置。而且微信对这些信息审核非常严格，不像在github上申请那么简单，在GitHub上，申请一个第三方应用的调用GitHub API 的权限是分分钟的事。以上说的这个事是流程图中没有涉及到的一个步骤，但在实际的应用中却是非常重要的一个步骤。第三方的应用首先要得到微信的基本信任才行，审核通过后，第三方应用才有权限访问微信的授权服务器进行后续流程图中的流程。

通过申请之后，微信会分配给我们的网站一些用户后续进行授权和认证的信息，AppId 和 AppSecret。有了这两个东西之后，我们的网站就可以跟微信授权服务器进行沟通了。

有了这两个东西之后，我们的网站就可以跟微信授权服务器进行沟通了。如果是github、微博或者QQ授权，咱们申请后，也会得到类似的两个配置项，在OAuth 2.0对应的就是client_id 和 client_secret,然后咱们在把流程中的重要步骤进行详细的解释, A 步骤中，客户端申请认证的 URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为 "code"
• client_id：表示客户端的 ID，必选项
• redirect_uri：表示重定向 URI ，可选项
• scope：表示申请的权限范围，可选项
• state：表示客户端的当前状态，这个状态值虽是一个可选项，但是对于预防 CSRF 攻击有重要的作用，请一定填写这个参数并进行严格验证，认证服务器会原封不动地返回这个值。

C 步骤中，服务器回应客户端的 URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

D 步骤中，客户端向认证服务器申请令牌的 HTTP 请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为 "authorization_code"。
• code：表示上一步获得的授权码，必选项。
• redirect_uri：表示重定向 URI，必选项，且必须与A步骤中的该参数值保持一致。
• client_id：表示客户端 ID，必选项。 

E 步骤中，认证服务器发送的 HTTP 回复，包含以下参数：

• access_token：表示访问令牌，必选项。
• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是 bearer 类型或 mac 类型。
• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

从上面代码可以看到 HTTP头信息中明确指定不得缓存，不得缓存是非常重要的配置项，切不可遗忘，不然很可能以后请求token的时候直接拿缓存中的 token，如果缓存中 token 早已失效的话，那就没有权限调用网络 API 获取指定的资源了。最后我们不光拿到了 access_token ,还拿到了一个叫 refresh_token 的令牌，我们必须在 access_token 过期后使用 refresh_token 在此请求一个新的 access_token,而无需再使用上面繁复的步骤获取 access_token,这样效率也会更高。这里还有一个重要的项需要说明一下，就是 scope 授权范围，scope 会指定客户端可以调取服务提供商的哪些 API 进行操作，可以是获取资源的 API，也可以是操作资源的 API。

如果你实在觉得官方给出的流程示意图太过恶心的话，你可以自己一边理解一边画，我就不画了，我也暂时不扩展本篇图文了，我会在后续的视频系列当中演示一下授权服务器和客户端两方是如何进行交互的，那套视频看完之后，你就会发现原来封装第三登录的开发包其实是一件非常简单的事情，甚至可以说简单到令人发指 ～

OK，本期图文我算是老老实实写了一篇，但是这不是最终版本，而且关于参数介绍的内容基本我都是直接剽窃的阮一峰的解释，但是对其中的某些项进行了必要的补充，最终版本会在视频系列结束后，重新对当前图文进行更新 ～