了解 OAuth 授权流程
如果您使用过 Google 登录、Twitter 身份验证或 GitHub 身份验证(仅举几个常见的例子),或者在其他 Web 应用程序中启用了集成,那么您可能熟悉 OAuth。
然而,即使您亲自实现了这一切,如果您像我一样,可能也从未深入思考过 OAuth 身份验证流程背后的原理。在本文中,我将从高层次讲解 Web 应用的标准 OAuth 2.0 流程(称为隐式流程)。之后,我们将深入探讨 PKCE 扩展(如果您还不了解它是什么,也不用担心),并解释为什么当今的最佳实践建议使用该流程。
需要说明的是,我并非 OAuth 方面的专家,但最近花了一些时间深入研究这个主题,觉得分享我的心得会很有帮助。如有任何建议,希望我能够改进这篇文章的内容,欢迎留言。
隐式流程
从用户的角度来看,身份验证流程非常简单。假设我点击了“使用 GitHub 登录”按钮。然后我会被引导到 GitHub 进行登录,如果这是我第一次登录,则需要授予权限。完成后,我会被带回原始网站,然后——瞧!——我登录成功了。
正如你所想象的,幕后还有很多事情要做。基本步骤如下(是的,这是一个简化版本):
- 应用程序请求用户授权
- 用户授权请求
- 授权服务器通过重定向 URI 发出访问令牌
- 应用程序使用令牌调用API
隐式流程中的步骤非常简单,如果您已经在 Web 应用程序中实现了 OAuth 2.0,那么您可能对这个流程并不陌生。需要注意的一个关键点是,访问 API 所需的令牌是通过重定向传递的。
隐式流的安全注意事项
网络安全始终需要权衡——更高的安全性通常意味着更高的复杂性。尽管上面看起来如此,但隐式流程实际上非常简单。虽然这种方法已经并将继续在各种 Web 应用程序中发挥作用,但安全专家曾经(并且仍然)担心它会留下一些潜在的攻击向量。
主要漏洞在于重定向返回的是有效的访问令牌。正如Brock Allen 所述:
隐式流最受批评的难以保护的方面也是定义隐式流的基本机制,即访问令牌从授权端点从令牌服务器返回到客户端。
其中一些担忧包括:
- “中间人”攻击可以拦截重定向,从而获得有效的访问令牌。
- 访问令牌可以注入到重定向 URL 中,并且没有验证机制来确保令牌没有被恶意注入。
- 重定向本身可以存储在浏览器历史记录中(甚至复制到云端),从而确保有效访问令牌的副本有可能泄露。
这并不是说隐式流不安全——而且也有一些实践可以缓解这些问题。然而,在 2012 年规范创建时,其中一些问题被认为是可以接受的,主要是因为当时浏览器在跨域访问方面的限制限制了更安全选项的可用性。
基于浏览器的应用程序的 OAuth 2.0 很好地概述了隐式流中的潜在威胁以及可用的缓解策略。
什么是 PKCE?
PKCE(全称“代码交换证明密钥”,发音为“pixie”)最初是为了解决使用 OAuth 2.0 的原生移动应用所特有的一个问题而开发的。该问题在于,应用密钥无法安全地驻留在应用中。在 Web 应用中,密钥会驻留在服务器上,在传递给授权服务器之前客户端无法访问。然而,在移动应用中,密钥需要驻留在应用代码中,而这可能会在反编译过程中被泄露。此外,移动应用中用于重定向的自定义 URL 方案也可能受到攻击。
PKCE 是 OAuth 2.0 的扩展,它通过在流程中添加一些步骤来解决此问题。
- 应用程序请求用户授权,并使用随机“代码验证器”创建“代码挑战”
- 代码质询被发送到授权服务器,用户进行身份验证
- 授权服务器存储代码质询并向应用程序返回代码
- 应用程序通过 POST 请求将代码和代码验证器发送到授权服务器
- 授权服务器验证代码质询/代码验证器并通过 POST 响应发出访问令牌
- 应用程序使用令牌调用API
虽然 PKCE 流程显然更为复杂,但仍有一些关键区别需要注意。首先,PKCE 没有预先配置的密钥。相反,它使用为每个请求生成的加密随机代码验证器。此外,PKCE 也没有重定向可供拦截。“中间人”攻击只能窃取授权码,而无法访问有效令牌。而且,由于没有重定向,也就没有可能包含有效令牌的浏览器历史记录。
有什么建议?
如果您的 Web 应用程序使用了隐式流程,并且一切顺利,那么您无需执行任何操作。但为了将来的开发,您可能需要参考OAuth 2.0 安全最佳实践文档,其中指出:
尽管到目前为止 PKCE 被推荐作为保护本机应用程序的机制,但此建议适用于所有类型的 OAuth 客户端,包括 Web 应用程序。
基本上,这并不是说隐式流程中发现了新的漏洞,只是 PKCE 提供了一种更安全的替代方案,如果可以选择的话,您应该使用它。您可以在Vittorio Bertocci 撰写的《OAuth2 隐式授权和 SPA》中找到一篇关于此处讨论的问题及其解决方案的优秀且实用的概述。
我希望这个概述对您有所帮助。
文章来源:https://dev.to/remotesynth/understanding-oauth-authorization-flows-10ok