每个资源服务器的 JWT 多个受众

Posted 2023-03-10

【中文标题】每个资源服务器的 JWT 多个受众

【英文标题】：JWT multiple audiences per resource server

【发布时间】：2016-06-23 01:33:19

【问题描述】：

在使用 OWIN 在 Web API 中使用 JWT 进行了数小时研究之后，我仍然对 Audience 所代表的目的感到困惑。有些页面说受众是验证令牌的资源服务器。其他人则认为 Audience 是访问资源服务器的客户端，并且实际上经常将此值称为 client_id 和 Audience 互换。

根据 JWT 规范，Audience 似乎是资源服务器 (https://www.rfc-editor.org/rfc/rfc7519#page-9)。因此，我认为每个 API 应用程序都不需要拥有多个受众。但是许多实现正在向单个 Web API 应用程序添加多个受众，并且 Microsoft 的 JwtBearerAuthenticationOptions 实现也允许这样做。

在这些实现中，他们交替使用受众和 client_id（这里是一个示例：https://auth0.com/docs/server-apis/webapi-owin）我觉得这将您的资源服务器与您的客户端紧密耦合，并在您的资源服务器上强制执行客户端声明。我觉得这是身份验证服务器的工作（因此能够根据 JWT 规范向令牌添加多个受众声明）。

我觉得我在这里遗漏了一些重要的东西。我的目标是能够开发可供多个客户端使用的多个 API，但必须在资源服务器和身份验证服务器上动态管理受众声明似乎违背了 JWT 的精神。然而，许多人以其他方式实现了它，甚至 MS 也允许每个资源服务器有多个受众，所以我希望在这里能澄清一些。

【参考方案1】：

audience 标识令牌的预期“消费者”。通常是应用程序 (API) 从客户端应用程序接收令牌。

需要 JWT 的服务需要检查（并验证）audience，以防止某人发送（有效）令牌，而该令牌是为其他人准备的。

您可以想象一种情况，例如 API-1 和 API-2 使用基于角色的安全性，并且用户获得声明 admin 用于 API-1。如果 API-2 不检查 audience，则用户有可能发送令牌（其中包含管理员声明）并成功（不应该）。

【讨论】：

所以我知道需要验证受众，但是您是否会认为每个 API 需要多个受众？如果 API 是受众，为什么需要配置任何 API 来验证多个受众？我只是无法想象一个用例。

不，我认为恰恰相反。您的令牌将有多个受众。这意味着它可以在许多 API 中使用。

那么关于为什么微软的 JwtBearerAuthenticationOptions 允许单个 API link 的多个受众有什么想法吗？

我的猜测是该实现假定身份验证服务器与资源服务器分离。受众是令牌应该有效的任何 API（资源服务器）。这允许单个授权服务器保护多个 API。