OAuth 2.1 的进化之路

f275de10e127ae8fd48f32c094722d2b.png

背景

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

e4de7da8f717407ec7df635a9fe7da97.png

不断进化的 OAuth 2.0

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

21922f8ebabe96027a505690c2fa1d57.png

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

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

3f9e09b897e431b987d1bde46e3dabb2.png

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

8b6bf83514755f5235bf766ddade7c7c.png

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

1ed394ccc6b597546758c628fde14765.png

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

823519e317b9659cd88c750b782bc7a3.png

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

fe3f1e6dc7a7b2bad30c5d6681153ada.png

总结

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

87970d433b73cc2636a58242b11c5e95.png

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]

1fba4b3616761e5a9ec7478d19136aed.png

相关链接

[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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
OAuth2.1OAuth2.0的一个扩展协议,它增加了一些额外的安全措施,例如公共客户端的验证和授权服务器的证书绑定。在iOS上实现OAuth2.1,您可以使用第三方库或自己编写代码来处理授权流程和令牌管理。 以下是使用第三方库实现OAuth2.1的步骤: 1. 添加OAuth2.1依赖库到您的项目中。常用的库有Auth0、Okta和AppAuth。这些库提供了OAuth2.1的实现,并且已经集成了大多数授权服务器的配置信息。 2. 配置应用程序和授权服务器。您需要在应用程序和授权服务器之间设置正确的重定向URI和客户端ID。这些信息将在授权流程中使用。 3. 实现授权流程。使用第三方库提供的方法来执行授权流程。通常,您需要向授权服务器发送请求以获取授权代码,并将授权代码交换为访问令牌。一些库提供了UI控件来处理授权流程,使它们更容易集成到您的应用程序中。 4. 存储和管理访问令牌。一旦您获得了访问令牌,您需要存储它并在需要时使用它来访问受保护的资源。您可以使用Keychain或其他安全存储机制来保存令牌。 5. 处理令牌过期和刷新。访问令牌有一个有效期,在过期之前,您需要使用刷新令牌来获取新的访问令牌。您可以使用库提供的方法来处理令牌过期和刷新。 使用第三方库可以简化OAuth2.1的实现,但您需要确保库与您的授权服务器兼容,并且符合您的安全要求。如果您需要更高的安全性和控制权,您可以编写自己的代码来处理OAuth2.1
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值