创建新的 OAuth2 客户端 ID 或每个客户是否有任何安全优势？
Is there any security benefit making a new OAuth2 client ID or each customer?
主要问题
我们应该为每个客户制作一个新的 OAuth 客户端 ID 和密码，还是只为我们应用程序的所有客户使用一个？
我的一些同事似乎认为，如果我们使用一个，并且它以某种方式泄漏，它将影响所有客户。因此，如果我们为每个客户制作一个，我们就会将损失降到最低。但我的（有限的）理解是，只有访问令牌/刷新令牌泄漏时，客户面临的主要风险才存在。
如果 OAuth 客户端 ID 和秘密泄露，有人可能会尝试通过网络钓鱼让某人相信他们允许我们的应用程序执行操作，而实际上他们实际上是在向恶意行为者提供访问权限。但这仍然需要客户上当受骗。即便如此，它只会影响上当的客户，而不会影响其他客户。
我不太确定的部分是我们在发现泄漏的客户端后采取的行动的影响 ID/Secret。我们可能需要删除 OAuth 客户端并制作一个新客户端，以防止可能出现泄露客户端的网络钓鱼尝试。
我相信在单一客户端 ID 模型上，这会中断所有客户的所有 API 调用，因为我们内部存储的访问令牌将是从以前的客户端 ID（我们刚刚删除的那个）生成的).用户需要打开我们的应用程序，再次登录到他们的 google 帐户，然后再次单击“允许”以从我们创建的新客户端 ID 中获取一个新的访问令牌，以允许我们调用 API 再次。如果我们为每个客户设置不同的客户端 ID，我们可以只对一部分客户或单个客户执行此过程。
但我也觉得在多客户ID模式下，如果一个客户ID确实泄露给了一个客户，我们怎么能确定它没有泄露给其他人呢？无论如何，您不想为所有客户获取新的客户 ID 吗？
我看到以下选项：
- 泄密者可以访问我们的 google 云项目，并且可以访问所有活动的客户端 ID。他们甚至可以为自己创建新的，因此拥有多个客户端 ID 无济于事。
- 泄密者获得了我们内部数据库的访问权限并能够对其进行解密。因此他们无论如何都可以获取存储在数据库中的所有客户端 ID，因此拥有多个客户端 ID 无济于事。 （他们也可能获得 tokens/refresh 令牌，这是一个更大的问题！）
- 有人错误地将客户端 ID 和密码包含在某些日志文件或电子邮件中。这可能会提供对少于完整客户端 ID 列表的访问，但我们又如何知道有多少日志文件泄露或发送了多少电子邮件？不改变所有这些不是一个坏习惯吗？
如果我忽略了什么，请帮助我。
这是一张供更多视觉思考者使用的图表（DB 中的值将是 encrypted/salted/etc。）
更新
由于似乎存在混淆，这里是 auth0.com
中的术语
资源所有者：School1、School2 等
客户端：我们的“应用”服务器
资源服务器：Google - 特别是“Google Workspace”或“Google Workspace Admin SDK APIs”（我相信）
授权服务器：Google - 特别是“Google身份”（我相信）
用户代理：浏览器
客户是资源所有者吗？：不是。学校拥有 chromebook 并通过 Google Workspace 管理 student/teacher 帐户。
客户端是在服务器上执行的网络应用程序吗？：是的。我们正在按照“授权代码流”从 Google 为每个客户获取访问令牌。我们将它们存储在我们的私人数据库中。
客户体验 - 他们下载并 运行 安装程序并输入许可证激活码。将托管带有 UI 的网站。 （假设 www.school1.com/App) It can be in their network, on cloud, wherever, they just need to make sure the hosting server's network can access to our internal server (let's say at 1.2.3.4). When opening www.school1.com/App 他们需要设置一个新的管理员帐户并登录。然后他们单击设置按钮并弹出 google 要求登录他们的 Google 帐户（这就是我们的方式获取访问令牌）。然后他们可以在浏览器中单击按钮与网站进行交互以执行操作。
API 流程 - 浏览器中的点击变成 API 对我们服务器 (1.2.3.4) 的调用，其中包含我们 authenticate/authorize 他们作为有效 App 客户进行调用的信息。如果获得授权，我们的服务器将使用我们内部存储的访问令牌来调用 Google APIs.
可选背景
我的公司正在寻求为使用 Google Workspace 管理其 Chromebook 的学校制作产品。
Google 已经有一些我们计划使用的 API。我们希望将这些与我们自己的业务逻辑相结合。作为一个虚拟示例，让我们假设我们知道学校希望每天在特定时间重启他们的 Chromebook。 issueCommand REST API 可用于重启。我们的应用程序将处理调用 API.
的调度
为了能够调用这些 APIs 需要使用 OAuth 2.0 的 Google 工作区管理员的许可来授权我们发出请求（不支持其他授权协议）。似乎有两种方法可以做到这一点。
- Service account apparently for server to server applications
- OAuth Client ID apparently for server-side web apps
服务帐户需要管理员登录他们的 Admin Console 并采取一系列手动步骤来授予我们的应用程序权限，其中 OAuth 客户端 ID 似乎对用户更友好。管理员只需登录 google 弹出窗口，就会显示我们请求的所有范围，只需单击“允许”[=17=]
（还有其他差异，例如即使管理员更改，服务帐户也会继续工作，但我们假设我们致力于 OAuth 客户端 ID）
授权码流程分为两部分：
- 浏览器中使用客户端 ID 并获取授权代码的前端通道请求
- 同时使用客户端 ID 和密码的反向通道请求，用于交换令牌的代码
如果这些泄漏，您可以在不影响最终用户的情况下替换客户端密码，因为它在 Web 后端和授权服务器之间是私有的。您可能需要重新部署 Web 应用程序，但这应该是您已经计划好的事情。
我建议保持客户端 ID 不变。这无论如何都不是秘密，当应用程序重定向他们登录时，任何最终用户都可以看到它是什么——例如，如果他们使用浏览器工具查看 HTTP 请求。
您只有一个应用程序，因此请使用一个客户端 ID 和密码。尝试做其他事情是行不通的，因为当用户开始身份验证时，您还不知道他们是谁，因为他们还没有确定自己的身份。
以上是标准的 OAuth，我会坚持使用它，因为它会产生简单的代码和易于管理的解决方案。
主要问题
我们应该为每个客户制作一个新的 OAuth 客户端 ID 和密码，还是只为我们应用程序的所有客户使用一个？
我的一些同事似乎认为，如果我们使用一个，并且它以某种方式泄漏，它将影响所有客户。因此，如果我们为每个客户制作一个，我们就会将损失降到最低。但我的（有限的）理解是，只有访问令牌/刷新令牌泄漏时，客户面临的主要风险才存在。
如果 OAuth 客户端 ID 和秘密泄露，有人可能会尝试通过网络钓鱼让某人相信他们允许我们的应用程序执行操作，而实际上他们实际上是在向恶意行为者提供访问权限。但这仍然需要客户上当受骗。即便如此，它只会影响上当的客户，而不会影响其他客户。
我不太确定的部分是我们在发现泄漏的客户端后采取的行动的影响 ID/Secret。我们可能需要删除 OAuth 客户端并制作一个新客户端，以防止可能出现泄露客户端的网络钓鱼尝试。
我相信在单一客户端 ID 模型上，这会中断所有客户的所有 API 调用，因为我们内部存储的访问令牌将是从以前的客户端 ID（我们刚刚删除的那个）生成的).用户需要打开我们的应用程序，再次登录到他们的 google 帐户，然后再次单击“允许”以从我们创建的新客户端 ID 中获取一个新的访问令牌，以允许我们调用 API 再次。如果我们为每个客户设置不同的客户端 ID，我们可以只对一部分客户或单个客户执行此过程。
但我也觉得在多客户ID模式下，如果一个客户ID确实泄露给了一个客户，我们怎么能确定它没有泄露给其他人呢？无论如何，您不想为所有客户获取新的客户 ID 吗？
我看到以下选项：
- 泄密者可以访问我们的 google 云项目，并且可以访问所有活动的客户端 ID。他们甚至可以为自己创建新的，因此拥有多个客户端 ID 无济于事。
- 泄密者获得了我们内部数据库的访问权限并能够对其进行解密。因此他们无论如何都可以获取存储在数据库中的所有客户端 ID，因此拥有多个客户端 ID 无济于事。 （他们也可能获得 tokens/refresh 令牌，这是一个更大的问题！）
- 有人错误地将客户端 ID 和密码包含在某些日志文件或电子邮件中。这可能会提供对少于完整客户端 ID 列表的访问，但我们又如何知道有多少日志文件泄露或发送了多少电子邮件？不改变所有这些不是一个坏习惯吗？
如果我忽略了什么，请帮助我。
这是一张供更多视觉思考者使用的图表（DB 中的值将是 encrypted/salted/etc。）
更新 由于似乎存在混淆，这里是 auth0.com
中的术语资源所有者：School1、School2 等
客户端：我们的“应用”服务器
资源服务器：Google - 特别是“Google Workspace”或“Google Workspace Admin SDK APIs”（我相信）
授权服务器：Google - 特别是“Google身份”（我相信）
用户代理：浏览器
客户是资源所有者吗？：不是。学校拥有 chromebook 并通过 Google Workspace 管理 student/teacher 帐户。
客户端是在服务器上执行的网络应用程序吗？：是的。我们正在按照“授权代码流”从 Google 为每个客户获取访问令牌。我们将它们存储在我们的私人数据库中。
客户体验 - 他们下载并 运行 安装程序并输入许可证激活码。将托管带有 UI 的网站。 （假设 www.school1.com/App) It can be in their network, on cloud, wherever, they just need to make sure the hosting server's network can access to our internal server (let's say at 1.2.3.4). When opening www.school1.com/App 他们需要设置一个新的管理员帐户并登录。然后他们单击设置按钮并弹出 google 要求登录他们的 Google 帐户（这就是我们的方式获取访问令牌）。然后他们可以在浏览器中单击按钮与网站进行交互以执行操作。
API 流程 - 浏览器中的点击变成 API 对我们服务器 (1.2.3.4) 的调用，其中包含我们 authenticate/authorize 他们作为有效 App 客户进行调用的信息。如果获得授权，我们的服务器将使用我们内部存储的访问令牌来调用 Google APIs.
可选背景
我的公司正在寻求为使用 Google Workspace 管理其 Chromebook 的学校制作产品。
Google 已经有一些我们计划使用的 API。我们希望将这些与我们自己的业务逻辑相结合。作为一个虚拟示例，让我们假设我们知道学校希望每天在特定时间重启他们的 Chromebook。 issueCommand REST API 可用于重启。我们的应用程序将处理调用 API.
的调度为了能够调用这些 APIs 需要使用 OAuth 2.0 的 Google 工作区管理员的许可来授权我们发出请求（不支持其他授权协议）。似乎有两种方法可以做到这一点。
- Service account apparently for server to server applications
- OAuth Client ID apparently for server-side web apps
服务帐户需要管理员登录他们的 Admin Console 并采取一系列手动步骤来授予我们的应用程序权限，其中 OAuth 客户端 ID 似乎对用户更友好。管理员只需登录 google 弹出窗口，就会显示我们请求的所有范围，只需单击“允许”[=17=]
（还有其他差异，例如即使管理员更改，服务帐户也会继续工作，但我们假设我们致力于 OAuth 客户端 ID）
授权码流程分为两部分：
- 浏览器中使用客户端 ID 并获取授权代码的前端通道请求
- 同时使用客户端 ID 和密码的反向通道请求，用于交换令牌的代码
如果这些泄漏，您可以在不影响最终用户的情况下替换客户端密码，因为它在 Web 后端和授权服务器之间是私有的。您可能需要重新部署 Web 应用程序，但这应该是您已经计划好的事情。
我建议保持客户端 ID 不变。这无论如何都不是秘密，当应用程序重定向他们登录时，任何最终用户都可以看到它是什么——例如，如果他们使用浏览器工具查看 HTTP 请求。
您只有一个应用程序，因此请使用一个客户端 ID 和密码。尝试做其他事情是行不通的，因为当用户开始身份验证时，您还不知道他们是谁，因为他们还没有确定自己的身份。
以上是标准的 OAuth，我会坚持使用它，因为它会产生简单的代码和易于管理的解决方案。