小编YoR*_*T83的帖子

我们的系统正在从单体架构转向微服务架构。微服务架构带来了我们需要解决的技术挑战，其中之一是 AuthN/AuthZ。

我们的方法是拥有一个身份验证服务，可以对用户进行身份验证并生成访问/刷新令牌 (JWT)。然后，访问令牌将通过微服务链在请求标头中传递，这样每个微服务只需验证令牌即可确定用户已成功通过身份验证。对于 AuthZ 部分，权限强制是在微服务本身中完成的。我的问题与 AuthZ 有关。

为了说明这个谈话，让我们举一个具体的例子，一个接待员想要注册一个新成员到他的保真计划，例如从一个 Web 应用程序。为了支持这个用例，我们假设系统有 2 个微服务，ReceptionService 和 MemberService。ReceptionService 提供了一个 REST API 来启动会员注册流程。它需要用户权限“注册”才能执行。MemberService 提供一个 REST API 来创建受 CRUD 权限保护的新成员资源。请求流将是：

1. 用户先前登录的 Web 应用程序将成员注册请求发送到 ReceptionService API，在标头中包含用户访问令牌。
2. ReceptionService 验证用户令牌，确保用户被授予“注册”权限，执行它需要执行的任何业务逻辑，最后向 MemberService API 发送成员创建请求，在标头中包含用户访问令牌。
3. MemberService 验证用户令牌，确保用户被授予“member.create”权限，最后创建成员。

为了针对这种情况设计解决方案，我的团队研究了以下假设/先决条件：

• 微服务必须始终强制执行权限（至少对于重要的 API 操作，例如创建成员）。因此，上面示例中 MemberService 的 CRUD 权限，即使产品经理可能只需要顶级“注册”权限。
• 因为拥有“顶级”权限而能够启动用例的用户必须能够完成它。这意味着它不会因为他缺少来自底层服务调用链中某处的另一个许可而出错。
• 管理员用户不必了解执行用例所需的权限链。在我们的示例中，管理员应该只能向用户提供“注册”权限。

为了能够完成上述示例，需要为用户分配 2 种不同的权限，这打破了我们的一些假设/先决条件。为了克服这个问题，我的一位同事提议考虑在我们的 AuthN 系统中将微服务声明为身份/用户，以便为它们分配适当的权限。最初提供的用户令牌随后将被调用链中的参与服务令牌替换。回到这个例子，新的请求流将是：

1. 用户先前登录的 Web 应用程序将成员注册请求发送到 ReceptionService API，在标头中包含用户访问令牌。

2. ReceptionService 验证用户令牌，确保用户被授予“注册”权限，执行它需要做的任何业务逻辑，最后向 MemberService API 发送一个成员创建请求，在头中包含它自己的服务令牌（因此替换原始用户令牌）。

3. MemberService 验证服务令牌，确保服务被授予“member.create”权限，最后创建成员。

使用此解决方案，AuthN 系统中的服务身份将通过从管理权限分配的管理员用户中过滤出来的方式进行标记。对服务身份的权限分配将是预先定义的，用户不可能对其进行配置。虽然它满足了我们的假设/先决条件，但我对这种方法几乎没有担忧：

• 在处理“谁做了什么”（审计）时，令牌中提供的用户身份和服务身份将被冷漠地列出。在我们的示例中，RegistrationService 将审核启动操作的实际用户，但 MemberService 将审核该操作是由“RegistrationService”执行的。在报告场景中，这意味着我需要协调来自两个系统的审计，以确定“实际上是谁创建了成员”，以某种方式使用相关 ID。
• 虽然我理解需要在不涉及实际用户的场景中为系统组件创建标识（自动批处理/第三方访问 ..），但我不喜欢在以下场景中用服务令牌替换用户令牌用户实际启动了用例。这是标准的设计模式吗？

难道我们的一些假设/先决条件是错误的？

• 例如，某些微服务即使
  在安全环境中仅被其他受控微服务访问，也不强制执行权限，这真的是一个安全漏洞吗？假设
  后者的答案是“不，它不会是一个安全漏洞”，那么如果明天，我需要让 MemberService API
  在安全环境之外也可以访问（例如，因为我将它 …