制作新的 OAuth2 客户端 ID 或每个客户是否有任何安全优势？

Question

主要问题

我们应该为每个客户创建一个新的 OAuth 客户端 ID 和密码，还是只为我们应用的所有客户使用一个？

我的一些同事似乎认为，如果我们使用一个，并且它以某种方式泄漏，它将影响所有客户。因此，如果我们为每位客户制作一个，我们可以最大限度地减少损失。但我的（有限）理解是，客户面临的主要风险是访问令牌/刷新令牌泄漏。

如果 OAuth 客户端 ID 和机密泄露，有人可能会尝试通过网络钓鱼让某人相信他们正在授予我们的应用执行操作的权限，而他们实际上是在向恶意行为者授予访问权限。但这仍然需要客户为网络钓鱼尝试而堕落。即使那样，它也只会影响喜欢它的客户，而不影响其他客户。

我不太确定的部分是我们在发现客户 ID/秘密泄露后采取的行动的影响。我们可能需要删除 OAuth 客户端并创建一个新客户端，以防止可能发生的网络钓鱼尝试。

我相信在单一客户端 ID 模型上，这会中断所有客户的所有 API 调用，因为我们内部存储的访问令牌将是从以前的客户端 ID（我们刚刚删除的那个）生成的访问令牌。用户需要打开我们的应用程序，再次登录他们的谷歌帐户，然后再次单击“允许”以从我们创建的新客户端 ID 中获取新的访问令牌，以允许我们再次调用 API。如果我们为每个客户提供不同的客户 ID，我们可以只为部分客户或单个客户执行此过程。

但我也觉得在多客户ID模型下，如果客户ID确实泄露给了一个客户，我们怎么能确定它没有泄露给其他客户呢？难道您不想为所有客户获取新的客户 ID 吗？

我看到以下选项：

1. 泄密者获得了我们的谷歌云项目的访问权限，并且可以访问所有活动的客户端 ID。他们甚至可以让自己成为新的，因此拥有多个客户端 ID 也无济于事。
2. 泄密者访问了我们的内部数据库并能够对其进行解密。所以他们无论如何都可以获得存储在数据库中的所有客户端 ID，因此拥有多个客户端 ID 并没有帮助。 （他们可能还能够获得访问令牌/刷新令牌，这是一个更大的问题！）
3. 有人错误地在某些日志文件或电子邮件中包含了客户端 ID 和密码。这可能会提供对完整客户端 ID 列表的访问权限，但我们又如何知道有多少日志文件泄露或发送了多少电子邮件？不改变所有这些不是一个坏习惯吗？

如果我忽略了什么，请帮助我。

这是更多视觉思想家的图表（数据库中的值将被加密/加盐/等）

更新 由于似乎有混淆，这里是来自auth0.com的术语

资源所有者：School1、School2 等

客户端：我们的“应用”服务器

资源服务器：Google - 特别是“Google Workspace”或“Google Workspace Admin SDK API”（我相信）

授权服务器：Google - 特别是“Google 身份”（我相信）

用户代理：浏览器

客户是资源所有者吗？：不是。学校拥有 chromebook 并通过 Google Workspace 管理使用它们的学生/教师帐户。

客户端是在服务器上执行的 Web 应用程序吗？：是的。我们遵循“授权代码流程”从 Google 为每个客户获取访问令牌。我们将它们存储在我们的私有数据库中。

客户体验 - 他们下载并运行安装程序并输入许可证激活码。将托管一个带有 UI 的网站。 （比方说www.school1.com/App）它可以在他们的网络中，在云上，在任何地方，他们只需要确保托管服务器的网络可以访问我们的内部服务器（比如说在1.2.3.4）。打开www.school1.com/App 时，他们需要设置一个新的管理员帐户并登录。然后他们点击设置按钮并弹出谷歌要求登录他们的谷歌帐户（这就是我们获取访问令牌的方式）。然后他们可以在浏览器中单击按钮与网站进行交互以执行操作。

API 流 - 浏览器中的点击成为对我们服务器 (1.2.3.4) 的 API 调用，并提供信息让我们验证/授权他们作为进行调用的有效应用程序客户。如果获得授权，我们的服务器将使用我们在内部存储的访问令牌来调用 Google API。

可选背景

我的公司正在寻求为使用 Google Workspace 的学校制作产品来管理他们的 Chromebook。

Google 已经有一些我们计划使用的 API。我们希望通过我们自己的业务逻辑来利用这些。作为一个虚拟示例，假设我们知道学校希望每天在特定时间重新启动他们的 Chromebook。 issueCommand REST API 可用于重新启动。我们的应用会处理调用 API 的调度。

要能够调用这些 API，需要 Google Workspace 管理员使用 OAuth 2.0 授权我们提出请求（不支持其他授权协议）。似乎有两种方法可以做到这一点。

1. Service account 显然是 server to server applications
2. OAuth Client ID 显然是 server-side web apps

服务帐户要求管理员登录到他们的Admin Console 并采取一系列手动步骤来授予我们的应用权限，其中 OAuth 客户端 ID 似乎对用户更友好。管理员只需登录谷歌弹出窗口并显示我们请求的所有范围，只需点击“允许”

（还有其他差异，例如即使管理员更改，服务帐户也将继续工作，但我们假设我们致力于 OAuth 客户端 ID）

Answer 1

授权代码流程分为两部分：

• 浏览器中使用客户端 ID 并获取授权码的前端通道请求
• 同时使用客户端 ID 和密钥的反向通道请求，以将代码交换为令牌

如果这些泄漏，您可以在不影响最终用户的情况下替换客户端密码，因为它在 Web 后端和授权服务器之间是私有的。您可能需要重新部署 Web 应用程序，但这应该是您已经制定好的计划。

我建议保持客户端 ID 不变。这无论如何都不是秘密，任何最终用户都可以看到应用程序重定向他们登录时的内容 - 例如，如果他们使用浏览器工具查看 HTTP 请求。

您只有一个应用程序，因此请使用单个客户端 ID 和密码。尝试不这样做是行不通的，因为当用户开始身份验证时，您还不知道他们是谁，因为他们还没有确定自己的身份。

以上是标准的 OAuth，我会坚持使用它，因为它会产生简单的代码和易于管理的解决方案。