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

【问题标题】：JWT Authorisation through multiple microservices通过多个微服务进行 JWT 授权
【发布时间】：2021-09-04 17:08:14
【问题描述】：

简短的问题

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

设置

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

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

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

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

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

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

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

【问题讨论】：

标签： jwt authorization microservices auth0

【解决方案1】：

在解决方案 B 中，您让 MS A 负责正确处理数据。在我看来，这只是自找麻烦，最终有人会设法以这种方式致电 MS A，以获得比他们可以访问的更多的数据。所以我会选择解决方案 A，或者它的一个变体。有几种方法可以在服务之间共享令牌 - 传递相同的令牌、嵌入令牌或交换令牌。前段时间写了一篇关于Token Sharing的文章，大家可以看看。

【讨论】：

【解决方案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 政策可能允许其中一种（或两种），但至少您可以在需要时灵活更改。

【讨论】：