OAuth 2.1 的进化之路

番茄西红柿发布于2021-11-23 09:51 / 2905人阅读

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

背景

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
The OAuth 2.0 Authorization Framework
The OAuth 2.1 Authorization Framework draft-ietf-oauth-v2-1-04
Its 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

专线服务服务器托管我的编程之路编程语言的进化风行云方舟生存进化的服务器线性表c语言2.1

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/124545.html

OAuth 2.1 带来了哪些变化

摘要：使用时不应该通过传递使用时不应该通过传递根据安全最佳实践章节在使用时您不应该把放到中第一浏览器地址栏本来就是暴露的第二可以查看浏览记录，找到。OAuth 2.1 是 OAuth 2.0 的下一个版本, OAuth 2.1 根据最佳安全实践(BCP), 目前是第18个版本，对 OAuth 2.0 协议进行整合和精简, 移除不安全的授权流程, 并发布了 OAuth 2.1 规范草案, 下面列出了...

xiangzhihong 2021-11-24 09:39 评论0 收藏0
javascript 闭包 ---- js进化之路

摘要：闭包利用的，其实就是作用域嵌套情况下，内部作用域可以访问外部作用域这一特性。之所以要将闭包和垃圾回收策略联系在一起，是因为这涉及到闭包的一些重要特性，如变量暂时存储和内存泄漏。因为匿名函数回调的闭包实际引用的是变量，而非变量的值。本文旨在总结在js学习过程中，对闭包的思考，理解，以及一些反思，如有不足，还请大家指教闭包---closure 闭包是js中比较特殊的一个概念，其特殊之处...

HtmlCssJs 2019-08-21 18:46 评论0 收藏0
前端框架的工程化之路

摘要：框架加冕时代年横空出世的前端框架的模块机制的模块机制相比老王老李的解决方案上增强了模块的约束性，和帮助开发者划分模块外，最重要的是解决了模块的运行时管理问题模块的初始化顺序问题和依赖的模块自动初始化问题。前端框架工程化之路人类的发展动力源于一个懒字，就如现在的大前端正是史前那群懒而聪明的切图仔进了软件工程的施工现场，怀揣着更少代码、更少沟通、更少错误、更少维护的梦想奔袭而来。从框架...

whatsns 2019-08-02 14:04 评论0 收藏0