OAuth 2.0 PKCE Flow 不会为伪装/网络钓鱼攻击打开大门吗？

Question

使用已安装应用程序的 OAuth 2.0 PKCE 流程（例如桌面应用程序/cli/客户端库），似乎没有什么可以阻止攻击者：

1. 使用原始应用程序获取client_id（client_id是公开的，可以从浏览器栏/源代码轻松复制）
2. 制作一个假应用程序来模仿原始应用程序
3. 使用假应用程序引诱用户授予访问权限，从而获得刷新令牌，这本质上意味着在请求的范围内进行完全访问

如果没有 PKCE，就很难伪造应用程序并获取刷新令牌，因为这需要攻击者获取client_secret. 在我看来，虽然 PKCE 提供了比隐式流更高的安全性改进，但它使得伪装使用 OAuth 2.0 的真实应用程序变得更加容易？

我正在使用 googlecloudsdk （gcloud），它似乎将client_id（甚至许多client_id/client_secret 对）硬编码到源代码中，并将其分发给客户端。我怀疑有什么可以阻止攻击者伪造 gcloud 从而获得对用户 GCP 环境的访问权限（为了证明，运行gcloud auth login它会在控制台中向您显示攻击者所需的网址。）任何人都可以澄清/帮助我了解发生了什么情况？

Answer 1

只是想跟进这个问题，因为我自己也有同样的问题，但我自己也回答了这个问题，我想补充一些这里没有说的内容：

当您在oauth2服务器上设置应用程序时，您必须设置一些redirect_uri允许在授权完成后返回的位置。这意味着创建像您所描述的网络钓鱼攻击的人在登录后无法返回自己的应用程序，并且永远不会收到代码。

有一种单独的攻击，您尝试从非法应用程序返回到合法应用程序，但这可以通过包含状态变量来解决。

Answer 2

私有 URI 方案可能是您在桌面上可以做的最好的方案，但并不像您所说的那样完美。这是我在桌面代码示例中使用的，但理想情况下我也想解决上述问题。

对于移动设备，您可以使用声明的 HTTPS 方案来解决问题 - 请参阅我添加到发送的 sllopis 帖子中的答案。

我会知道更新的 OAuth 2.1 本机应用程序指南- 请参阅第 10 节 - 但我认为您无法完全解决这个问题。

预计最终用户会谨慎对待他们安装的桌面应用程序，以降低这种情况的风险。希望操作系统支持将来能够提供更好的加密选项。