OAuth 2.1 的进化之路

OAuth 2.1 的进化之路_第1张图片

背景

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 整体看起来就像一个迷宫一样。

OAuth 2.1 的进化之路_第2张图片

不断进化的 OAuth 2.0

在 OAuth 2.0 核心规范 (RFC 6749)中, 定义了四种授权类型:授权码、隐式、密码和客户端凭据, 如下:

OAuth 2.1 的进化之路_第3张图片

相信大家都很熟悉, 在 OAuth 2.0 中,最安全也是使用最普遍的就是授权码模式, 而对于本地应用,移动应用来说, 通常会使用隐式和密码授权, 这两种本身就是不安全的, 因为这些属于公开的客户端, 本身没有能力保护客户端机密, 但是当时并没有其它好的方案。

为了解决 OAuth 2.0 对公开客户端的授权安全问题, PKCE (RFC 6379)协议应运而生, 全称是 Proof Key for Code Exchange,PKCE 的原理是, 对于公共的客户端, 如果不能使用客户端秘钥(client_secret), 那客户端就提供一个自创建的证明 (code_verifier) 给授权服务器,其中使用了加密算法, 授权服务器通过它来验证客户端。

OAuth 2.1 的进化之路_第4张图片

后来,"OAuth 2.0 for Native Apps"(RFC 8252)规范发布,推荐原生应用也使用授权码 + PKCE。

OAuth 2.1 的进化之路_第5张图片

随着技术不断地发展, 出现了设备授权的场景, 这里设备指智能电视,打印机等, 和传统的PC或者手机不同, 这种设备是缺少浏览器或者键盘的,那 OAuth 2.0 常规的授权模式肯定是不能满足的, 于是就出现了设备授权(Device Grant) 。

OAuth 2.1 的进化之路_第6张图片

在 OAuth 2.0 安全最佳实践(Security BCP)中, 弃用了隐式和密码授权,并且推荐所有的客户端都应该使用 Authorization Code + PKCE 的组合。

OAuth 2.1 的进化之路_第7张图片

最终, 调整后的 OAuth 授权模式会更加精简, 转换成下面三种, 这也是 OAuth 2.1 的思想, 参考安全最佳实践(BCP),取其精华, 去其糟粕。

OAuth 2.1 的进化之路_第8张图片

总结

归根结底, OAuth 2.1 并不是要推翻 OAuth 2.0,而是根据其安全最佳实践(BCP), 移除不安全的授权流程, 并且对扩展协议进行整合, 让原本复杂如迷宫的 OAuth 2.0 规范成为更易用,更安全的授权规范。

OAuth 2.1 的进化之路_第9张图片

References

The OAuth 1.0 Protocol
The OAuth 2.0 Authorization Framework
The OAuth 2.1 Authorization Framework draft-ietf-oauth-v2-1-04
It's Time for OAuth 2.1
OAuth 2.0 for Native Apps
OAuth 2.0 Device Authorization Grant
Proof Key for Code Exchange by OAuth Public Clients

你可能感兴趣的