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

Question

问题简述

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

设置

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

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

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

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

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

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

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

Answer 1

在解决方案 B 中，您将很多责任交给 MS A，以正确处理数据。在我看来，这只是自找麻烦，最终有人会设法以这种方式调用 MS A，以获得比他们可以访问的更多的数据。所以我会选择解决方案 A 或其变体。令牌可以通过多种方式在服务之间共享 - 传递相同的令牌、嵌入令牌或交换令牌。我之前写过一篇关于 Token Sharing 的文章，你可以看看。

Answer 2

我认为这取决于 - 根据情况，两种选择都可以。

以下是一些需要考虑的事项。

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

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

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