OAuth 2.1 的进化之路
Posted dotNET跨平台
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了OAuth 2.1 的进化之路相关的知识,希望对你有一定的参考价值。
![null](https://image.cha138.com/20211220/b71c8c55a6874eaa97f3ca24b7bbee32.jpg)
背景
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](https://image.cha138.com/20211220/fa4501692f904b5eb0d20f6780d1fc26.jpg)
不断进化的 OAuth 2.0
在 OAuth 2.0 核心规范 (RFC 6749)中, 定义了四种授权类型:授权码、隐式、密码和客户端凭据, 如下:
![null](https://image.cha138.com/20211220/eb86af9cd23c432e85abbb383ce94f6b.jpg)
相信大家都很熟悉, 在 OAuth 2.0 中,最安全也是使用最普遍的就是授权码模式, 而对于本地应用,移动应用来说, 通常会使用隐式和密码授权, 这两种本身就是不安全的, 因为这些属于公开的客户端, 本身没有能力保护客户端机密, 但是当时并没有其它好的方案。
为了解决 OAuth 2.0 对公开客户端的授权安全问题, PKCE (RFC 6379)协议应运而生, 全称是 Proof Key for Code Exchange,PKCE 的原理是, 对于公共的客户端, 如果不能使用客户端秘钥(client_secret), 那客户端就提供一个自创建的证明 (code_verifier) 给授权服务器,其中使用了加密算法, 授权服务器通过它来验证客户端。
![null](https://image.cha138.com/20211220/7729e29dac2d428d820fa4e6a5a0b699.jpg)
后来,"OAuth 2.0 for Native Apps"(RFC 8252)规范发布,推荐原生应用也使用授权码 + PKCE。
![null](https://image.cha138.com/20211220/bb889f4e6a814697ab6fd13eae522c9d.jpg)
随着技术不断地发展, 出现了设备授权的场景, 这里设备指智能电视,打印机等, 和传统的PC或者手机不同, 这种设备是缺少浏览器或者键盘的,那 OAuth 2.0 常规的授权模式肯定是不能满足的, 于是就出现了设备授权(Device Grant) 。
![null](https://image.cha138.com/20211220/1a88f6a990f842be98149f164803dc42.jpg)
在 OAuth 2.0 安全最佳实践(Security BCP)中, 弃用了隐式和密码授权,并且推荐所有的客户端都应该使用 Authorization Code + PKCE 的组合。
![null](https://image.cha138.com/20211220/67a608db259b48eeab1dc86a45adfd08.jpg)
最终, 调整后的 OAuth 授权模式会更加精简, 转换成下面三种, 这也是 OAuth 2.1 的思想, 参考安全最佳实践(BCP),取其精华, 去其糟粕。
![null](https://image.cha138.com/20211220/bbafc11253df4f3883113d71240cd1e7.jpg)
总结
归根结底, OAuth 2.1 并不是要推翻 OAuth 2.0,而是根据其安全最佳实践(BCP), 移除不安全的授权流程, 并且对扩展协议进行整合, 让原本复杂如迷宫的 OAuth 2.0 规范成为更易用,更安全的授权规范。
![null](https://image.cha138.com/20211220/0efcc632d83e4303bf8321e3fa9ca2ca.jpg)
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](https://image.cha138.com/20211220/d330f4cc34354755af1feabccad8e87a.jpg)
相关链接
[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
以上是关于OAuth 2.1 的进化之路的主要内容,如果未能解决你的问题,请参考以下文章