在spring boot中保护内部微服务调用的最佳方法是什么

我正在草拟一个简单的应用程序，它将包含三个松散耦合的服务：身份验证（在spring security下使用OAuth2）、概要文件和首选项、数据收集。我正在尝试确定保护或构建这些服务之间安全调用的最佳方法。考虑下面两个用户案例。在每种情况下，用户都已通过身份验证，请求将包含到初始服务端点的有效JWT令牌：

案例1：用户希望编辑他们对首选水果的偏好。应用程序将对配置文件/首选项服务进行身份验证调用，以获取他们的首选项，然后发回更新的首选项

案例2：他们向数据收集服务提出请求，该服务将调查杂货店的水果价格API。这需要从配置文件和首选项服务中查找他们喜欢的水果

我的问题是，对于上面的案例2，保护配置文件和首选项服务的最佳方式是什么。我觉得有三种可能的方法：

每个内部请求都需要包括任何身份验证 要在当前用户上下文中传递的标头

每个内部请求都需要以其他方式进行身份验证 作为API用户的方式

每个内部请求都需要到达不同的端点，即 未公开并连接到负载平衡器中，用于内部 仅限交通

---

这是Spring Boot的一个现成功能吗？

由于微服务带来了独立应用程序的概念，“智能应用程序和哑管道”，您已经可以摆脱解决方案3了。，这需要某种基于网络的安全性

如果我可以用我自己的话来解释你的问题：

要执行的操作：客户端->应用程序1->应用程序2
问题：如何保护从App1到App2的调用

剩下的两个解决方案：

当App1调用App2时，App1将从客户端接收的令牌转发给App2

当App1调用App2时，App1以自己的名称（客户端凭据授予）请求一个令牌，并将其传递给App2

解决方案2的问题。可能会带来权限问题：
如果调用App1的客户端没有调用App2的权限（作用域），App1仍将调用App2，因为App1将以自己的名称拥有该权限

---

结论：解决方案1。是唯一可行的解决方案。

在（3）的情况下，您将在整个应用程序中创建单点故障。选项（1）似乎是最好的，因为您将使用OAuth2的强大功能，并使用用户上下文“为用户”执行操作！如果在解决方案1的上下文中，客户机不是实际的客户机，而是另一个服务在使用它的数据呢？在这种情况下，您认为应该怎么做？您好@heisenberg，我的用词可能很差，因为另一个服务也是OAuth术语中的客户机，但您的问题看起来像我文章中的解决方案2。如果Service1代表自己向Service2发起请求（不首先涉及最终用户），Service1需要使用OAuth客户端凭据授权获取访问令牌。