小编dli*_*liu的帖子

使用已安装应用程序的 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它会在控制台中向您显示攻击者所需的网址。）任何人都可以澄清/帮助我了解发生了什么情况？

正如 google记录的那样，开发人员可以使用gcloud auth print-identity-token生成仅用于开发的 id_token 来向 Cloud Run 进行身份验证。如果我对生成的 id_token 进行 base64 解码，我可以看到aud声明设置为 32555940559.apps.googleusercontent.com，这是谷歌云 sdk的 client_id ：

这是一个例外，在列出的规则服务到服务的身份验证，它说target_audience需要被设置为接收服务的URL（例如，https://xxxxx.run.app）。就是aud和target_audience同样的事情？

最后，除了使用 googlecloudsdk（即gcloud auth print-identity-token不存在映像）之外，还有其他方法可以使用用户帐户而不是服务帐户进行身份验证吗？