OAuth2/OIDC：如何识别客户端应用程序

Question

TL/DR：我的问题在本消息的末尾，但基本上我是在问从 Web 服务角度识别客户端应用程序的标准是什么？

更多背景信息：我们公司正在努力重建我们的身份验证和授权机制一年了。 与许多公司一样，我们有多个网络服务，它们之间进行通信 (M2M)，可以从我们的内部组织或外部（由外部公司）调用。为了提高安全级别和互操作性，我们已转向 OAuth2/OIDC 协议（基于 Keycloak 作为授权服务器），并且运行良好。

我们现在面临的问题是，为了通知客户重大变更、折旧、警告等（以及提高审核能力），我们需要 识别调用我们每个 Web 的客户应用程序，而不是用户-services（然后将电子邮件或其他内容附加到此身份，但这超出了我的问题范围）。我们不能依赖该用户帐户，因为可以从另一个客户应用程序合法地使用该用户帐户。我们不能依赖低级协议（例如，由于 NAT 和许多原因，使用源 IP 来识别它们是不可能的）。我们假设我们既不能依赖访问令牌也不能依赖 ID 令牌（例如

azp

声明），因为这些令牌可以在下游由其他进程（不是请求令牌的各方）合法使用（并且因为

azp

声明的规范含糊不清，取决于实现 - 例如，如果我是正确的，Google 不会遵守该标准）。

所以我的问题是：

1. 您能否确认 OAuth2 和 OIDC 协议并非旨在处理此用例（或者我遗漏了什么？）？
2. 因此，我们应该实现一些自定义逻辑（例如，附加信息，由调用者拥有，由某个机构签名，为每个请求传递一些 HTTP 标头到我们的 Web 服务，类似的东西）或者是否有一些众所周知的逻辑有这个标准吗？
3. 另一种选择可能是依赖 API 密钥，但这让我们感到不舒服，因为我们会失去 OAuth2/OIDC 及其互操作性优势、标准等？

非常感谢您的专业知识！

我们尝试过的：如上所述，我们评估了多种方法并确定了其中一些方法的优缺点，但我们无法确定一种标准且通用的方法来执行我们想要的操作（识别客户端应用程序，而不是识别客户端应用程序）用户，而不失去标准的好处）。

Answer 1

这里有一些问题：

识别客户

在 M2M 设置中，您使用客户端凭据授予，并可能在访问令牌中使用

client_id

声明来区分调用者，然后作为 API 逻辑的一部分查找他们的特定权限。

您的令牌发行逻辑还可能会向访问令牌发出自定义声明，例如

department_id

（如果这对您的业务有意义）。所以这个机制是支持的。

API 边界

您对访问令牌的下游重用的担忧应通过发布范围和受众声明来管理。每个 API 应验证访问令牌是否满足其自身的要求。

范围通常是业务领域。例如，范围为

retail/sales

的访问令牌将无法用于需要

commercial/sales

范围的 API。受众可以代表单个 API 或一组逻辑 API。

安全地传递价值

传输安全值时，将它们发送给访问令牌。这样做意味着 API 可以信任收到的值，因为它们已由您的授权服务器断言。

特别是，如果涉及用户 ID，则不应在纯 HTTP 标头中发送它。这不是一个安全的设计，因为恶意 API 客户端可能会提供不正确的值。

因此，当涉及用户 ID 时，请避免客户端凭据流，以将用户身份和其他安全值保留在访问令牌中。

使用令牌共享技术，例如在 API 之间转发原始客户端的访问令牌或 RFC 6893 中的令牌交换标准，这允许您在转发访问令牌之前调整访问令牌的范围和受众。