jwt - 通过多个微服务进行 JWT 授权

简短的问题

对于从微服务 A 访问数据但微服务 A 需要来自微服务 B 的数据的用户，处理 JWT 身份验证的正确方法是什么？

设置

我正在使用 Auth0 来发布和处理身份验证和授权。

我设置了两个微服务。用户在前端登录，需要加载基于租户的计费信息。

微服务 A 是一种聚合服务，它与多个不同的服务进行通信，以便为不同类型的数据类型提供标准化的响应。

微服务 B 由微服务 A 查询，以检索用户拥有的车辆信息。

哪种解决方案是正确的方法？

解决方案A： 用户登录时发给用户的令牌将被MS A用来与MS B进行通信。MS A本质上是转发用户提供的令牌。

解决方案 B： MS A 拥有自己的 JWT，它具有超级管理员权限，可以访问来自 MS B 的任何资源。MS A 将在访问来自 MS B 的资源时使用此令牌，并且 MS A 将负责确保用户无法访问的资源是未在聚合数据集中返回。

标签： jwtauthorizationmicroservicesauth0

我认为这取决于 - 这两个选项都可以，具体取决于场景。

这里有几点需要考虑。

微服务 B 是否进行任何资源所有者授权，例如使用sub来自用户 JWT 的声明？如果是这样，通过用户访问令牌可能会更容易。注意：通常我只使用从 JWT 推断出的数据用于 authZ 逻辑。如果您需要资源所有者 ID 之类的内容作为业务逻辑的一部分，则应在请求有效负载中明确包含此内容，以便后端服务也可以使用 M2M 令牌使用该服务。
使用 Auth0，机器 MUA（每月唯一身份验证）需要付费。这与用户 MUA 的成本是分开的。对于企业帐户，默认值为 1000 个 M2M MUA。增加这个数字非常便宜，但仍然需要考虑。一般来说，您应该将 M2M 令牌配置为具有更长的有效期（例如 1-2 天）并使用令牌缓存。通常内存中的缓存就足够了，但是如果您正在构建无服务器应用程序（例如 AWS Lambda、Azure 函数应用程序等），您可能需要一个分布式缓存。对于 M2M 令牌，所有这些都是额外的工作、复杂性和潜在成本（例如分布式缓存）。
M2M 身份验证有额外的网络请求（对 Auth0）。这可以通过使用令牌缓存来缓解，但也需要考虑一些事情。
微服务 B 是否可以公开访问？如果是，您可能有一些安全考虑，因为用户将能够使用他们的访问令牌（合法获得）直接调用微服务 B，但他们可能会以您不希望的方式篡改请求。

我工作的公司混合了您提到的两种方法（通常取决于场景）。我们有一些用于令牌缓存等的辅助工具，这使这两种方法都足够简单，但是如果您要使用 M2M 令牌，您可能需要预先做一些额外的工作。

最后一件事要提；在实现像微服务 B 这样的“传递”服务时，我认为最好确保用户和机器令牌都可以使用该服务。您的 authZ 策略可能允许其中一个（或两者），但至少您可以在需要时灵活更改。