提问人：Ryan Moore 提问时间：11/15/2023 更新时间：11/16/2023 访问量：25
Google Identity Services：什么会阻止其他人使用我的客户端 ID？
Google Identity Services: What stops someone else using my client ID?
问：
对于传统的 oauth2 授权代码流，浏览器会重定向到应用程序服务器上列入允许列表的 URL，这意味着前端应用程序永远不会收到该代码。
在实现 react-oauth2/google 时，我发现默认的“uxmode”是“popup”，它不需要任何应用程序服务器交互，并在用户使用 Google 进行身份验证后将 ID 令牌返回给前端。只需要将“授权的 JavaScript 源”配置为服务后端，我认为这仅适用于 CORS，不应被视为安全。
这里的建议是，返回的 ID 令牌应该发送到后端并进行验证（包括检查受众是否是我们的客户 ID）。然后，我们可以相信用户就是他们所说的那个人，并颁发一个应用程序令牌以用于后端 API）。
有了新的流程，什么可以阻止某人简单地使用我的公开客户端 ID 来冒充我？毫无戒心的用户可能会访问冒充网站并使用 google 进行身份验证，此时恶意应用程序具有有效的 Google ID 令牌，其中我的客户端 ID 作为受众，并且可以与我的后端交换应用程序令牌。
答：
0赞
Tore Nestenius
11/16/2023
#1
如果黑客使用您的 clientId，他们仍将被重定向回您的应用程序。重定向 URL 在 Google 中为您的客户端 ID 进行了硬编码，在此示例中，它可以保护您，并且无法将它们重定向到黑客应用程序。
评论
0赞
Ryan Moore
11/16/2023
uxmode： 弹出窗口不使用重定向。我有这个工作，javascript 交付了一个 ID 令牌（根据原始问题中的链接进行身份验证所需的所有令牌），没有任何重定向。我甚至在这个客户端上没有任何允许的重定向 URL。
0赞
Ryan Moore
11/16/2023
我一直在思考更多，可能的答案是 uxmode=popup 依赖于浏览器强制执行 origin 标头，类似于 uxmode=redirect 依赖于浏览器不与原始页面共享重定向 URL。在任何一种情况下，如果浏览器受到威胁（或者所有这些都是通过外部应用程序完成的），安全性就会崩溃。
0赞
Tore Nestenius
11/16/2023
是的，如果客户端或浏览器遭到入侵，那么无论如何它总是游戏结束（例如，由于 XSS 或浏览器扩展被入侵）。
评论