大家好,我是 橘长,此前我们带来了 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 中的令牌机制」的解读,感谢你的关注,可在我的首页找到我,如果你觉得有所收益,欢迎点赞、转发、评论,感谢认可!