为什么你应该弃用资源所有者密码凭证(ROPC)授权类型
资源所有者密码凭证(ROPC)授权类型是一种遗留的 OAuth 2.0 流程,存在安全风险,应该被弃用。在本文中,我们将说明为什么你应该避免在应用程序中使用 ROPC。
介绍
资源所有者密码凭证(ROPC)授权类型,也被称为密码授权类型,是一种 OAuth 2.0 流程,允许应用程序用用户的用户名和密码交换访问令牌。它首次在 OAuth 2.0 规范中引入,旨在支持遗留应用程序,例如 HTTP 基本认证或无法使用更安全的 OAuth 令牌化流程的遗留本地应用程序。
然而,ROPC 授权类型存在多个安全风险,已在OAuth 2.0 安全最佳实践中标记为不得使用。
最近,我们收到了一些客户的提问,请求提供有关实施 ROPC 授权类型的指导或支持。在本文中,我们将解释为什么你应该避免使用 ROPC 授权类型,特别是在你的新应用程序中。
ROPC 授权类型与授权码流相比
ROPC 授权类型的工作原理
ROPC 授权类型是一种简单的流程,用户的用户名和密码会被用来交换访问令牌。客户端应用程序直接收集用户的凭证,并直接将其发送到授权服务器。授权服务器验证凭证后,会向客户端颁发访问令牌。
授权码流的工作原理
相比之下,授权码流是推荐的用于 Web 应用程序的 OAuth 2.0 流程。它涉及客户端应用程序、授权服务器和用户浏览器之间的多步操作和重定向。授权码流更加安全,因为它不会将用户的凭证暴露给客户端应用程序。
ROPC 授权类型和授权码流的主要区别在于 ROPC 将用户的凭证暴露给客户端应用程序,而授权码流则不会。用户的凭证应该在授权服务器内保密保存。每当客户端应用程序代表用户请求资源时,它应该将用户重定向到授权服务器,以验证和授权客户端应用程序。这可以让客户端应用程序端保留最少的授权数据。
ROPC 授权类型的安全风险
1. 用户凭证暴露
如前所述,ROPC 授权类型会将用户的凭证暴露给客户端应用程序。这是一个重大的安全风险,因为客户端应用程序可能会存储或记录用户的凭证,并且在用户不知情的情况下重新获得授权。
特别是对于像移动应用程序或单页面应用程序这样公共客户端应用程序,客户端应用程序容易被注入或反向工程,从而提取用户的凭证。在用户的浏览器中运行的移动应用程序或单页面应用程序不能保密地保存秘密。因此,它们在未经暴露用户凭证的情况下无法验证用户。
即使资源所有者与客户端应用程序有着可信赖的关系,客户端应用程序在整个验证过程中充当了中间人的角色,可能会被其他恶意行为者攻击。恶意行为者可以窃取用户的凭证,并冒充用户访问用户的资源。
根据客户端应用程序的安全状况,有多种方法可以窃取用户的凭证,比如键盘记录器、网络钓鱼攻击或恶意软件。更不用说客户端凭证会在每次授权请求中通过网络传输,这进一步增加了凭证被截获的风险。
想象一下,如果你有多个使用 ROPC 授权类型的应用程序,凭证暴露的潜在风险将成倍增加。
2. ROPC 不支持用户同意
ROPC 授权类型不支持用户同意。当客户端应用程序直接收集用户的凭证时,用户没有机会检查和批准客户端应用程序对其资源的访问。这是对用户隐私和信任的侵犯。
用户应该有权决定哪个客户端应用程序可以访问其资源以及访问时间长短。特别是对于第三方应用程序,用户同意机制对于保护资源所有者的数据至关重要,并且对于遵守 GDPR 之类的数据保护法规也至关重要。
3. ROPC 不支持多因素认证
多因素认证 (MFA) 是一种安全实现,要求用户提供两个或更多的验证因素来访问其资源。它为身份验证过程增加了额外的安全层。ROPC 授权类型不支持 MFA。相反,它的身份验证过程仅限于单一因素,令牌请求仅基于用户的凭证。因此,无法使用 ROPC 授权类型实现基于挑战的认证机制,如 SMS OTP、电子邮件 OTP 或 WebAuthn。
ROPC 与现代应用程序不兼容
ROPC 授权类型旨在支持那些无法支持现代 IAM 系统单点登录 (SSO) 或联合身份的遗留应用程序。
1. ROPC 与 SSO 不兼容
单点登录 (SSO) 是一种现代身份验证架构,允许用户登录一次,便可无缝访问多个应用程序。
在 SSO 架构中,中心化的身份提供者 (IdP) 起着关键作用。它管理用户的身份验证会话,并向客户端应用程序颁发令牌。客户端应用程序无需直接收集用户的凭证,用户的凭证保密地保存在 IdP 内。
ROPC 授权类型不支持 SSO。它要求客户端应用程序直接收集用户的凭证,这破坏了 SSO 架构。它与 OpenID Connect (OIDC) 或 SAML 等现代 SSO 系统不兼容。
2. ROPC 与联合身份不兼容
与 SSO 架构类似,联合身份允许用户使用其现有的身份访问多个第三方应用程序。用户可以将多个社交帐户(如 Google、Facebook 或 Twitter)链接到中心化的 IdP,并使用这些社交帐户与客户端应用程序进行验证。所有联合身份都由 IdP 管理,而客户端应用程序无需了解用户的身份验证细节。
相反,ROPC 授权类型需要客户端应用程序直接收集用户的凭证。它限制了客户端应用程序支持联合身份的能力,并将用户的身份数据暴露给客户端应用程序。
结论
资源所有者密码凭证(ROPC)授权类型是一种遗留的 OAuth 2.0 流程,存在巨大的安全风险,应该被弃用。它将用户的凭证暴露给客户端应用程序,不支持现代安全机制如 MFA 或 SSO。我们强烈建议你避免在应用程序中使用 ROPC 授权类型。如果你有依赖 ROPC 授权类型的遗留认证系统,考虑迁移到更安全的 OAuth 2.0 流程,如授权码流或客户端凭证流。
联系我们,如果你需要帮助将安全的用户身份验证和授权服务集成到你的应用程序中,或将遗留的基于密码的身份验证系统迁移到更安全的 OAuth 2.0 流程。我们随时为你提供帮助,构建安全的现代应用程序。