![null f275de10e127ae8fd48f32c094722d2b.png](https://i-blog.csdnimg.cn/blog_migrate/c3af79c2a7ea5634a862fc3c776a68ff.png)
背景
2010年, OAuth 授权规范 1.0 (rfc 5849) 版本发布, 2年后, 更简单易用的 OAuth 2.0 规范发布(rfc 6749), 这也是大家最熟悉并且在互联网上使用最广泛的版本, 在2012年的时候, iPhone 5 是全新的, 微软最新的浏览器还是 IE9, 单页面应用在当时还被称作 "Ajax 应用", CORS(跨域资源共享)还不是一个W3C标准。
到现在, 网络和移动领域发生了巨大的变化, 当时发布的授权协议标准已经远远不能满足现在的场景和需求, 为了应对这种不断变化的局面, OAuth 社区多年来一直在修补和扩展 OAuth 规范, OAuth 的格局也不断扩大, 越来越多的围绕 OAuth 2.0 core 的扩展授权规范出现, 也让 OAuth 2.0 整体看起来就像一个迷宫一样。
![null e4de7da8f717407ec7df635a9fe7da97.png](https://i-blog.csdnimg.cn/blog_migrate/40e49a229dded69fa1666fc2adb5c376.png)
不断进化的 OAuth 2.0
在 OAuth 2.0 核心规范 (RFC 6749)中, 定义了四种授权类型:授权码、隐式、密码和客户端凭据, 如下:
![null 21922f8ebabe96027a505690c2fa1d57.png](https://i-blog.csdnimg.cn/blog_migrate/80fefa5463921122f07205851a49ca20.png)
相信大家都很熟悉, 在 OAuth 2.0 中,最安全也是使用最普遍的就是授权码模式, 而对于本地应用,移动应用来说, 通常会使用隐式和密码授权, 这两种本身就是不安全的, 因为这些属于公开的客户端, 本身没有能力保护客户端机密, 但是当时并没有其它好的方案。
为了解决 OAuth 2.0 对公开客户端的授权安全问题, PKCE (RFC 6379)协议应运而生, 全称是 Proof Key for Code Exchange,PKCE 的原理是, 对于公共的客户端, 如果不能使用客户端秘钥(client_secret), 那客户端就提供一个自创建的证明 (code_verifier) 给授权服务器,其中使用了加密算法, 授权服务器通过它来验证客户端。
![null 3f9e09b897e431b987d1bde46e3dabb2.png](https://i-blog.csdnimg.cn/blog_migrate/7318a6838c1cf84d894f37ec892d2996.png)
后来,"OAuth 2.0 for Native Apps"(RFC 8252)规范发布,推荐原生应用也使用授权码 + PKCE。
![null 8b6bf83514755f5235bf766ddade7c7c.png](https://i-blog.csdnimg.cn/blog_migrate/0f629a85e1a51db2aa77704fbd3d8a6d.png)
随着技术不断地发展, 出现了设备授权的场景, 这里设备指智能电视,打印机等, 和传统的PC或者手机不同, 这种设备是缺少浏览器或者键盘的,那 OAuth 2.0 常规的授权模式肯定是不能满足的, 于是就出现了设备授权(Device Grant) 。
![null 1ed394ccc6b597546758c628fde14765.png](https://i-blog.csdnimg.cn/blog_migrate/dd012aa0d0b1431bbc960a0918f29979.png)
在 OAuth 2.0 安全最佳实践(Security BCP)中, 弃用了隐式和密码授权,并且推荐所有的客户端都应该使用 Authorization Code + PKCE 的组合。
![null 823519e317b9659cd88c750b782bc7a3.png](https://i-blog.csdnimg.cn/blog_migrate/2c608fd753b8dea5a8346920c67e2b1a.png)
最终, 调整后的 OAuth 授权模式会更加精简, 转换成下面三种, 这也是 OAuth 2.1 的思想, 参考安全最佳实践(BCP),取其精华, 去其糟粕。
![null fe3f1e6dc7a7b2bad30c5d6681153ada.png](https://i-blog.csdnimg.cn/blog_migrate/c7e661ef968295d46f011eed3d4dd88e.png)
总结
归根结底, OAuth 2.1 并不是要推翻 OAuth 2.0,而是根据其安全最佳实践(BCP), 移除不安全的授权流程, 并且对扩展协议进行整合, 让原本复杂如迷宫的 OAuth 2.0 规范成为更易用,更安全的授权规范。
![null 87970d433b73cc2636a58242b11c5e95.png](https://i-blog.csdnimg.cn/blog_migrate/ce96b46c50809c1de6f4b72356b4880f.png)
References
The OAuth 1.0 Protocol[1]
The OAuth 2.0 Authorization Framework[2]
The OAuth 2.1 Authorization Framework draft-ietf-oauth-v2-1-04[3]
It's Time for OAuth 2.1[4]
OAuth 2.0 for Native Apps[5]
OAuth 2.0 Device Authorization Grant[6] Proof Key for Code Exchange by OAuth Public Clients[7]
![null 1fba4b3616761e5a9ec7478d19136aed.png](https://i-blog.csdnimg.cn/blog_migrate/2b641ade5c346fe98eeefb75806beabd.png)
相关链接
[1]
The OAuth 1.0 Protocol: https://datatracker.ietf.org/doc/html/rfc5849[2]
The OAuth 2.0 Authorization Framework: https://www.rfc-editor.org/rfc/rfc6749[3]
The OAuth 2.1 Authorization Framework draft-ietf-oauth-v2-1-04: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/[4]
It's Time for OAuth 2.1: https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1[5]
OAuth 2.0 for Native Apps: https://www.rfc-editor.org/rfc/rfc8252.html[6]
OAuth 2.0 Device Authorization Grant: https://datatracker.ietf.org/doc/html/rfc8628[7]
Proof Key for Code Exchange by OAuth Public Clients: https://www.rfc-editor.org/rfc/rfc7636.html