大家好，我是 橘长，此前我们带来了 OAuth 2.0 的第一篇「 掀开 OAuth 2.0 授权初貌」的解读。
今天继续解读 「 OAuth 2.0 中的授权许可协议」。
一、OAuth 历史
一上来就直接 OAuth 2.0，那自然会有疑问，有 1.0 协议吗？
自然是有的，以前大多数应用都是 Web 端，OAuth 1.0 时期的授权许可类型就一种，它想着用一套协议去应对各种业务场景。
随着IT业务的不断发展，移动端、web端等多元化场景，OAuth 1.0 协议有点应对不过来，以及存在固化攻击等安全问题，因此 OAuth 2.0 应运而生了。
了解一个技术的历史演变，有助于对这项技术未来走势的判断，这是洞见性思维，而非直觉。
二、四种授权许可协议
OAuth 2.0 官方提供了四种授权协议，分别如图所示。
其中授权码许可机制是最完备，最安全的一种，当我们掌握了最难的那种，自然而言去掌握其他几种就会很快上手。
1、资源拥有者许可机制
简单理解其实就是账号名和密码，通过账号名和密码去换取凭据，再通过凭据去访问业务接口。
2、隐式许可机制
这是 OAuth 2.0 最不安全的一种授权许可机制。
存在的意义是针对于 无 Server 端的 APP 应用架构。
APP 静态页中展示了一系列第三方入口，前端直接用客户端配置等去换取凭据，相当不安全的做法。
3、客户端凭据许可机制
受保护资源没有明确的资源拥有者的时候。
比方说淘宝的 logo，此时第三方软件可以通过“唯一标识 + 密钥”的形式去换取凭据。
4、授权码许可机制
四种角色都存在，引入授权码的概念来做中转，通过授权码去换取凭据，这是 OAuth 2.0 中最安全、最完备的做法。
三、微信授权说明授权码许可机制
?接下来，橘长用简化版流程说明“微信授权授权码许可机制”：
第一步：微信用户访问第三方软件，第三方软件请求微信授权服务获取授权链接
第二步：第三方软件拿到授权链接后，第一次重定向引导用户到授权页
第三步：用户点击确认授权，授权服务颁发授权码回调第三方软件（第二次重定向）
第四步：第三方软件通过拿到的授权码加上相关颁发的配置去换取凭据
第五步：授权服务颁发凭据，第三方软件拿到凭据去访问受保护资源，进而拿到数据
四、总结
今天橘长带大家分析了 OAuth 的发展历史以及授权许可类型，只需要记住两个点：
1、关注一个技术的发展历史，有助于培养自身的洞见性思维
2、OAuth 2.0 有四种授权协议：客户端凭据许可机制、隐式许可机制、资源拥有者许可机制、授权码许可机制，尤其是授权码许可机制一定要掌握。
下一篇橘长将给大家带来「 OAuth 2.0 中的令牌机制」的解读，感谢你的关注，可在我的首页找到我，如果你觉得有所收益，欢迎点赞、转发、评论，感谢认可！