锐客网

  1. 首页 > it技术 > >

OAuth|OAuth 2.1 的进化之路

OAuth|OAuth 2.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|OAuth 2.1 的进化之路
文章图片

不断进化的 OAuth 2.0 【OAuth|OAuth 2.1 的进化之路】在 OAuth 2.0 核心规范 (RFC 6749)中, 定义了四种授权类型：授权码、隐式、密码和客户端凭据, 如下:
OAuth|OAuth 2.1 的进化之路
文章图片

相信大家都很熟悉, 在 OAuth 2.0 中,最安全也是使用最普遍的就是授权码模式, 而对于本地应用，移动应用来说, 通常会使用隐式和密码授权, 这两种本身就是不安全的, 因为这些属于公开的客户端, 本身没有能力保护客户端机密, 但是当时并没有其它好的方案。
为了解决 OAuth 2.0 对公开客户端的授权安全问题, PKCE （RFC 6379）协议应运而生, 全称是 Proof Key for Code Exchange，PKCE 的原理是, 对于公共的客户端, 如果不能使用客户端秘钥（client_secret）, 那客户端就提供一个自创建的证明 (code_verifier) 给授权服务器，其中使用了加密算法, 授权服务器通过它来验证客户端。
OAuth|OAuth 2.1 的进化之路
文章图片

后来，"OAuth 2.0 for Native Apps"（RFC 8252）规范发布，推荐原生应用也使用授权码 + PKCE。
OAuth|OAuth 2.1 的进化之路
文章图片

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

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

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

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

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
OAuth|OAuth 2.1 的进化之路
文章图片

    推荐阅读


    上一篇：Study|Study Blazor .NET（四）数据绑定

    下一篇：女儿十八岁