OAuth 2.1 的进化之路_oauth2.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.0

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

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

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

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

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

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

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

总结

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

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]