【问题标题】:Understanding benefits of PKCE vs. Authorization Code Grant了解 PKCE 与授权码授予的好处
【发布时间】:2022-02-03 07:30:30
【问题描述】:

我是 OAuth 领域的新手,我正在尝试了解使用 PKCE 相对于传统授权代码授予的好处。 (我的许多假设可能是错误的,所以我会感谢您的更正。)

我是一名移动应用开发人员,根据 OAuth 文档,客户机密不能硬编码在公共客户的应用代码中。避免硬编码客户端密码的原因是黑客可以反编译我的应用程序并获取我的客户端密码。

拥有我的客户端密码和我的 redirect_url 的黑客可以开发一个虚假的应用程序。如果最终用户(User1)下载了真实应用程序和黑客应用程序(两者),则虚假应用程序可以监听真实应用程序回调并从中获取授权码。使用授权码(来自回调)和客户端密码(通过反编译我的应用程序窃取),黑客可以获得授权令牌和刷新令牌,并能够获取例如 User1 的数据。

如果其他用户下载真假应用程序,他们的数据也将处于危险之中。我对吗?黑客是否需要两者,或者他/她是否可以仅使用授权码进行攻击?图片第五步是否需要客户端秘钥和授权码?

这种攻击称为拦截攻击。

为了解决在公共客户端应用程序中对客户端机密进行硬编码的问题,并使黑客无法获取客户端机密和窃取令牌,PKCE 应运而生。使用 PKCE,客户端应用程序代码不需要对客户端密码进行硬编码,因为 PKCE 不需要该信息来获取最终用户的令牌。

PKCE 流创建一个随机字符串,将其转换为 SHA-256 哈希值和 Base64。在图像的第二个点中,该编码字符串被发送到带有 client id 的身份验证服务器。然后在回调中发送授权码,如果任何恶意应用拦截代码,它将无法获取令牌,因为图像的第五点需要由合法应用创建的原始随机字符串。

这很好,但是如果不再需要客户端密码来获取访问 User1 数据的令牌,我该如何避免黑客开发一个使用 PKCE 流和我的客户端 ID 并获取令牌的虚假应用程序认为该应用是合法应用的用户?

由于图像的第五步不再需要客户端密码来获取令牌,任何人都可以使用我的公共客户端 ID 开发假应用,如果任何用户下载假应用并执行 OAuth 流程,黑客可以获得其令牌并访问该用户数据!

我说的对吗?

【问题讨论】:

    标签: security oauth-2.0 oauth token pkce


    【解决方案1】:

    如果不再需要客户端密码来获取访问 User1 数据的令牌,我如何避免黑客开发使用带有我的客户端 ID 的 PKCE 流的假应用程序并获取认为该应用程序的用户的令牌是合法的吗?

    OAuth 2.0 或 PKCE 不能防止“假应用”。

    PKCE 确实可以防止设备上的恶意应用窃取用于另一个应用的令牌。例如。想想银行应用程序,如果设备上的另一个应用程序可以获取银行应用程序正在使用的令牌,那就不好了。您的图片中就是这种情况,PKCE 可以缓解这种情况。

    由于图像的第 5 步不再需要客户端密码来获取令牌,因此任何人都可以使用我的公共客户端 ID 开发假应用。

    移动应用程序无法保护客户端机密,类似于 JavaScript 单页应用程序。因此,根据 OAuth 2.0,这些客户端是 公共客户端,而不是 机密客户端。只有机密客户可以以安全的方式保护客户机密,只有那些应该使用客户机密。 PKCE 对于公共客户来说是一种很好的技术,但也可以用于机密客户

    如果任何用户下载虚假应用程序并执行 oauth 流程,黑客就可以获得它的令牌并访问该用户数据!

    联系 Apple Store 或 Google Play 商店以获取“假应用”,或使用例如反恶意软件应用程序。这就是针对“假应用程序”的缓解措施。 PKCE 仅在同一设备上的另一个应用程序试图窃取为另一个应用程序(例如银行应用程序)颁发的令牌时缓解这种情况。

    【讨论】:

      猜你喜欢
      • 2018-01-12
      • 2019-08-22
      • 2020-11-25
      • 1970-01-01
      • 2021-03-24
      • 2018-10-25
      • 1970-01-01
      • 2020-08-23
      • 1970-01-01
      相关资源
      最近更新 更多