1。第一种方式

Question

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

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

哪种方法最适合？

SpaClient 
Scope = A, B, C

Spa App从身份提供商处获得SpaClient的令牌。

使用令牌从Spa App调用A api，B api，并且A api使用相同的令牌调用C api。

2。第二种方式

SpaClient 
Scope = A, B

CClient
Scope = C

Spa App从身份提供商处获得SpaClient的令牌。

调用A api，B api和A api调用Identity Provider的其他方法，以获取CClient的令牌并使用CClient的令牌调用C Api。

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

SpaClient 
Scope = A, B

Spa App从身份提供商处获得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

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

如果在您的示例中，服务在代表用户的操作中同时出现了来自用户界面的触摸A和C的同步请求，请使用OAuth2的授权码流程，其中相同的令牌将从A流向C。

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

无论如何使用微服务以及如何将其放置在调用流中，都不保证微服务处于开放状态而无需客户端进行任何身份验证。