如何在应用程序发起调用时处理微服务之间的身份验证

Question

我读了很多关于微服务架构中身份验证的文章，最终得出的结论是 JWS 安全性是必经之路。这意味着

• 当客户端发出请求时，它需要具有有效的访问令牌
• 请求的身份验证在网关级别进行，授权在微服务应用程序级别进行
当客户端向微服务 A 发出请求，
• 我需要调用微服务 B 时，我需要重复使用相同的访问令牌来向 A 和 B 发出请求。

但是当请求的发起者不是客户端时，我仍然有很多疑问，它是另一个应用程序，来自微服务架构外部和内部

>

如果我们有一个整体式应用程序，并且想要调用微服务，我们计划开发一种带有 API 密钥的轻型身份验证模型，该模型将在网关级别转换为 JWS。因此，应用程序不需要维护会话（使用令牌和刷新令牌），并且只需使用 API 密钥即可发出请求，但在网关级别，该 API 密钥将被转换为 JWS，因此微服务架构中的所有内容都将使用 JWS 作为授权模型。

但是，如果我们想将微服务 A 与微服务 B 进行通信，并且发起调用的是微服务 A，该怎么办？这意味着在同一微服务体系结构中的应用程序到应用程序。这是我的疑问：

1. 如果我遵循上面解释的相同逻辑，我需要通过网关将 API 密钥转换为 JWS，只是为了传达两个微服务，这没有意义。
2. 同一架构内微服务之间的通信是否需要进行身份验证/授权？我们正在使用 Istio 进行双向 TLS
3. API 密钥是应用到应用身份验证的好主意吗？或者最好将所有内容都使用 JWS？
4. 如果要走的是另一种完全不同的身份验证/授权模型。这是否意味着应用程序需要支持这两种模式？（这将增加所有微服务的复杂性）

这个话题让我感到困惑，所以非常欢迎有关这个主题的任何帮助

Answer 1

是否考虑过使用客户端凭据流？看起来整体式应用调用微服务就足够了。它是专为应用到应用通信而设计的 OAuth 流。您的整体式应用程序将能够轻松获取 JWS 访问令牌，只需向授权服务器发出一个请求。

就个人而言，我不会使用 API 密钥，而是使用客户端凭据流。它是基于标准的，因此您不必重新发明轮子。

如果您将 Istio 与 mTLS 一起使用，则通信已经过身份验证。如果我没记错的话，你也可以在 Istio 中定义一些授权规则（允许哪个服务调用哪个服务等）。如果整体式应用位于同一网络中，则可以使用它对其进行身份验证，并且根本不需要客户端凭据流。