微服务体系结构中docker容器之间的身份验证，绕过JWT auth进行内部调用

我有以下docker架构，由docker compose协调：

• 服务1：前端应用程序，react应用程序
• Service2:ExpressJS服务器
• 服务3:Django服务器

这三个应用程序通过HTTP API调用相互通信。谁可以给谁打电话没有限制。每个应用程序都是外部公开的

用户在前端应用程序（Service1）上进行身份验证，并解析一个JWT，该JWT随后可以传递给其他每一个后续调用，然后每个其他服务都有一个身份验证层来验证JWT调用

我的问题是：如何在没有任何用户活动（没有JWT）的情况下验证从Service2到Service3的呼叫？

这是cron或维护作业所必需的

我的第一个解决方案是在docker compose中创建一个具有固定子网的docker网络，如下所示：

networks:
  our-network:
    ipam:
      driver: default
      config:
        - subnet: "172.100.100.0/24"

然后，在Service2和Service3中，我允许来自该子网的API调用未经身份验证。 我担心这可能是一个安全问题，不知道是否有更好的解决方案。

JWT令牌通常使用令牌颁发者的私钥进行签名。将JWT令牌作为一个标记是一个很好的实践

JWT令牌通常可以通过两种方式进行验证：

• 通过调用发卡机构的，但这会增加更多的延迟
• 使用来自颁发者的缓存公钥进行本地验证-难以添加注销功能

如果使用缓存解决方案，这不会增加太多延迟，那么JWT颁发者必须实现一个包含对颁发者发布其公钥的位置的引用的缓存解决方案

如果你使用Kubernetes，你可以使用一个sidecar来为应用程序进行令牌验证。开发人员在每个应用程序中实现令牌验证功能并不是那么有趣，所以这是一个有趣的替代方案。您还可以使用此解决方案轻松添加授权规则

我们如何在没有任何用户活动（没有JWT）的情况下验证从Service2到Service3的调用

当Service2收到来自用户的请求，并通过JWT验证时-它代表用户向Service3发出请求，因此它也应该将JWT令牌传递给Service3-以便Service3可以操作并仅使用属于用户的资源，例如从数据库获取。这可以在没有用户干预的情况下完成（直到JWT过期）

这是cron或维护作业所必需的

---

对于代表用户执行的作业，通常需要将过期时间较长的JWT令牌存储在数据库中。通常，这可以由用户撤销，通常在3个月左右到期，然后用户可能需要再次验证（或超过3个月-取决于您的需要）。重要的是，此类令牌具有较低的权限，通常只有作业所需的权限。

今天来到这里询问相关问题。稍后将发布。感谢您的回答，但恐怕它不完全符合我的用例。我知道JWT身份验证方法以及如何使用它，但问题是如何在没有用户交互的情况下绕过API调用的JWT身份验证。OPA还假设实际有一个用户需要验证，而我需要在没有任何我了解的用户的情况下打一些内部电话，并在我的回答中添加了一个澄清。。。。同时将JWT传递给下一个服务。@NicolòGasparini我还扩展了我对乔布斯的回答。