【问题标题】：Do we need to authenticate for Internal Microservice?我们需要对内部微服务进行身份验证吗？
【发布时间】：2019-07-28 19:13:24
【问题描述】：

我有一个水疗应用和三个 API（A、B、C）

A、B 是公共微服务，C 是内部微服务。

哪种方式最适合？

1。第一种方式

SpaClient 
Scope = A, B, C

Spa 应用从身份提供者处获取 SpaClient 的令牌。

Spa App使用token调用A api、B api，A api使用同一个token调用C api。

2。第二种方式

SpaClient 
Scope = A, B

CClient
Scope = C

Spa 应用从身份提供者处获取 SpaClient 的令牌。

调用A api、B api、A api 调用附加到Identity Provider 以获取CClient 的令牌并使用CClient 的令牌调用C Api。

在这种情况下，身份提供者需要在每个请求上生成新的令牌，以便从 A API 调用 C Api。

SpaClient 
Scope = A, B

Spa 应用从身份提供者处获取 SpaClient 的令牌。

使用token从Spa App调用A api、B api，A api不带token调用C api（C Api中没有认证）。

【问题讨论】：

【解决方案1】：

C Api 是需要保护的资源。您可以在全球范围内执行此操作，这可能都很好。但我认为可能存在的问题是如何访问流中的资源？

如果资源具有用户依赖信息，那么您将如何传递这些信息？ A Api 可以发送任何sub，声称它代表这个用户。 C Api 无法分辨。以及如何防止B Api 访问资源？

出于可维护性和安全性原因，我会在所有 api 上实现相同的安全性。在这种情况下，问题可以通过使用delegation来解决。

这样就没有其他资源或客户端可以访问C Api。资源知道哪个客户端进行了调用，并确定它代表他们所说的用户，因为这是访问令牌的一部分，并且可以由 IdentityServer 验证（自省）。

【讨论】：

【解决方案2】：

应该为所有服务实施身份验证，无论它是否向用户公开。

如果服务代表用户执行操作，例如在您的示例中来自 UI 的同时触摸 A 和 C 的同步请求，请使用 OAuth2 的授权代码流，其中相同的令牌将通过 A 流向 C。

如果服务不像批处理作业或流平台的消费者那样代表用户行事，请使用 OAuth2 的客户端流程，其中 C（在您的示例中）将从授权服务器获取自己的令牌。

在不要求客户端进行任何身份验证的情况下让微服务保持打开状态是不安全的，无论它是如何使用的以及它在调用流中的位置。

【讨论】：