我计划在我的微服务上实现 JWT 身份验证，以实现零信任架构。用户将通过前端微服务生成 JWT 令牌。每个后续请求都将包含此 JWT，该 JWT 将转发到后端服务，因此服务可以自行验证用户身份，而不是从前端服务获取简单的用户 ID。该方案在两种情况下失败
在这两种情况下，用户都无法通过登录凭据生成新的 JWT 令牌。除了 JWT 之外，我是否应该实施一次和目的特定的令牌来解决这些问题，还是有更好的选择？
tl/dr：可以让后端接受用户 ID 作为零信任架构的一部分。更重要的部分是您的服务必须对后端进行身份验证，并且后端的适当部分应该只接受来自您的服务（而不是来自最终用户）的请求。因此，您的问题是尝试将最终用户的身份验证令牌用于最终用户不应直接访问的服务。让您的服务通过后端验证自己，然后传递用户 ID 就可以了。
我认为关键是您混淆了某些后端系统的“用户”是谁。
这在您的第二个示例中最为清楚：删除非活动用户。这是一个仅限系统的进程。用户永远不会自己触发此操作。后端是执行操作的“用户”，即使用户帐户受到影响。因此，首先使用用户的访问令牌删除用户并没有任何意义。用户不会自己向后端发出这些请求。实际上，用户无论如何都不应该访问这些端点。如果用户以某种方式设法访问后端以尝试删除其帐户，则应拒绝其访问令牌-此端点仅供系统使用，（可能）不供用户删除自己。因此，通过使用用户的身份验证令牌来执行这些系统操作，
对于您的第一个示例，情况有点模糊，因为是用户发出了触发后续操作的初始请求。但是，无论如何，总体情况似乎仍然相同 - 后端进程正在对用户数据采取行动。该系统的“用户”不是实际的最终用户，而是您自己系统的一部分。它恰好代表您的用户行事。
简而言之，如果您有不打算由用户直接调用的后端服务，那么这些服务不应该接受用户的访问令牌。
那么如何实施零信任系统呢？自然地，就像你试图做的那样——你只是在验证错误的人。不是用户需要对后端进行身份验证，而是使用后端的任何服务都需要对自己进行身份验证。这可能与 JWT 相关，也可能不相关。拥有一个只有“cron”服务知道的身份验证令牌可能是一件简单的事情，并且它使用它来向您的后端进行身份验证。这些细节取决于你。
但是，我认为这是唯一真正的答案。这些服务需要以自己的方式向后端的相关部分进行身份验证，后端的这些部分应该只接受来自经过身份验证的服务的请求，而不是来自具有最终用户 JWT 的最终用户的请求。您显然必须以涵盖凭证轮换问题（如果相关）的方式为您的服务构建身份验证方法。但是，由于您不会在该过程中使用用户密码，因此不必担心。