使用OAuth 2.0 PKCE Flow for Installed App(例如桌面应用程序/cli/client库(，似乎没有什么可以阻止攻击者：
- 使用原始应用程序获取
client_id(client_id是公共的，可以很容易地从浏览器栏/源代码中复制( - 制作一个模拟原始应用程序的假应用程序
- 使用假应用程序引诱用户授予访问权限，从而获得刷新令牌，这本质上意味着在请求的范围内完全访问
如果没有PKCE，很难伪造应用程序并获得刷新令牌，因为这需要攻击者获得client_secret。在我看来，尽管PKCE比隐式流提供了安全性改进，但它使伪装使用OAuth 2.0的真实应用程序变得更加容易？
我使用的是googlecloudsdk(gcloud(，它似乎将client_id(甚至许多client_id/client_secret对(硬编码到源代码中，然后分发给客户端。我怀疑有什么可以阻止攻击者伪造gcloud，从而访问用户的GCP环境(为了证明，运行gcloud auth login，它会在控制台中向您显示攻击者需要的url。(有人能澄清/帮助我了解发生了什么吗？
我只是想跟进这个问题，因为我自己也有同样的问题，但我自己也回答了，我想添加一些这里没有说的内容：
在oauth2服务器上设置应用程序时，必须设置多个redirect_uri，授权完成后可以返回这些位置。这意味着，像你描述的那样制造网络钓鱼攻击的人在登录后无法返回自己的应用程序，也永远不会收到代码。
有一种单独的攻击，你试图从非法应用程序返回到合法应用程序，但这可以通过包含状态变量来解决。
私有URI方案可能是桌面上最好的方案，但并不像您所说的那样完美。这是我在桌面代码示例中使用的，但理想情况下，我也想解决上述问题。
对于移动设备，您可以使用声称的HTTPS方案来解决问题-请参阅我在sllopis发送的帖子中添加的答案。
我知道更新的OAuth 2.1本地应用指南(请参阅第10节(，但我认为您无法完全解决这个问题。
预计最终用户对他们安装的桌面应用程序要小心，以降低这种情况下的风险。希望操作系统的支持将在未来提供更好的加密选项。