如何在 OIDC/OAuth2 流程中识别“资源服务器”上的“客户端应用程序”

Posted 2023-03-28

【中文标题】如何在 OIDC/OAuth2 流程中识别“资源服务器”上的“客户端应用程序”

【英文标题】：How to identify the "client application" at the "resource server" in a OIDC/OAuth2 flow

【发布时间】：2020-02-02 09:30:52

【问题描述】：

我有多个客户端应用程序连接到微服务设置中的多个不同 API 服务。我使用 OIDC 进行用户身份验证，然后使用 OAuth2 访问令牌为客户端应用程序授权 API 服务（资源服务器）。

如果许多不同的应用拥有具有所需范围的访问令牌，则它们可以调用相同的 API。 Tha API 服务器仅检查访问令牌中是否存在声明以允许调用。

我们的其中一个 API 服务（例如，订票应用）需要知道调用者是谁，以进行一些特定于应用的验证，并记录一些发票等。

我们如何仅通过访问令牌JWT 知道调用者是谁？虽然 OIDC 提到 azp 作为一种方法来判断谁是 Identity Token 的授权方，但没有为 Access Token 定义等效项。有人有什么想法吗？

【参考方案1】：

您可以使用 OAuth 2.0 (OAuth 2.0 Token Introspection) 定义的令牌自省端点

公开此端点以验证令牌的有效性以及检索一些信息，例如范围、最终用户的用户名，以及对于您的情况而言重要的是客户端的客户端 ID (Introspection Response)。

或者，检查您的授权服务器的访问令牌 JWT 配置。由于您获得了 JWT，因此可以将客户端 ID 添加到 JWT，这将避免这种额外的自省调用。

【讨论】：

谢谢。这种验证不存在显示clientid 的强制声明。即使在token introspection 端点中，clientid 根据规范也是可选的。我们正在开发自己的授权服务器，基于经过认证的 OpenID 提供程序库，我认为我们应该能够在 JWT 本身中添加 clientid。

是的，您应该能够将此参数添加到响应中。规范只要求有效状态。但正如我强调的那样，它提到了其他可能的参数。 OAuth 2.0 是一个框架，您可以在其上构建您的解决方案（例如：OpenID Connect 就是这样的扩展）所以在实施时要保持这种灵活性。唯一的要求是遵循标准建议