我们需要对Internal Microservice进行身份验证吗？

Question

我有一个spa应用程序和三个API（A，B，C）

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

哪种方式最适合？

1. First way

SpaClient 
Scope = A, B, C

Spa App从Identity Provider获取SpaClient令牌。

使用令牌从Spa App呼叫A api，B api，A api使用相同的令牌呼叫C api。

SpaClient 
Scope = A, B

CClient
Scope = C

Spa App从Identity Provider获取SpaClient令牌。

呼叫A api，B api和A api呼叫身份提供者，以获取CClient的令牌并使用CClient令牌呼叫C Api。

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

SpaClient 
Scope = A, B

Spa App从Identity Provider获取SpaClient令牌。

使用令牌从Spa App调用A api，B api，并且A api在没有令牌的情况下调用C api（在C Api中不进行身份验证）。

Answer 1

C Api是一种需要保护的资源。你可以在全球范围内做到这一点，这可能都很好。但我认为可能是一个问题是如何访问流中的资源？

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

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

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

Answer 2

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

如果服务代表用户，如同在UI的同步请求中触及示例中的A和C，请使用OAuth2的授权代码流，其中相同的令牌将通过A流向C.

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

无论客户端如何使用以及在呼叫流程中的位置如何，都不需要保护微服务而不需要客户端进行任何身份验证。