Нужно ли проходить аутентификацию для внутреннего микросервиса?

Question

У меня есть приложение spa и три API (A, B, C)

A, B общедоступные микросервисы и C внутренний микросервис .

Какой способ лучше для этого?

1.Первый способ

SpaClient 
Scope = A, B, C

Spa App получает токен SpaClient от провайдера идентификации.

Вызовите Api, B api из Spa App с помощью токена, а A api вызывает C api с помощью того же токена.

2.Второй способ

SpaClient 
Scope = A, B

CClient
Scope = C

Приложение Spa получает токен SpaClient от провайдера идентификации.

Вызовите дополнительные функции A api, B api и A api для Identity Provider, чтобы получить токен CClient ивызывайте C Api с помощью токена CClient.

В этом случае провайдеру идентификации необходимо генерировать новый токен при каждом запросе, чтобы вызывать C Api из A Api.

3.Третий способ

SpaClient 
Scope = A, B

Spa App получает токен SpaClient от провайдера идентификации.

Вызовите Api, B api из Spa App с помощью токена, а A api вызывает C api без токена (нетаутентификация в C Api).

Нужна ли аутентификация для внутреннего микросервиса?

Answer 1

C Api - это ресурс, который необходимо защитить. Вы можете сделать это на глобальном уровне, что может быть хорошо. Но я думаю, что проблема может быть как получить доступ к ресурсу в потоке ?

Если ресурс содержит информацию, зависящую от пользователя, то как вы собираетесь передавать эту информацию? A Api может отправить любого sub, утверждая, что это от имени этого пользователя. C Api не может сказать. И как вы препятствуете B Api доступу к ресурсу?

Из соображений удобства обслуживания и безопасности я бы применил одинаковую защиту на всех API. И в этом случае проблему можно решить с помощью делегирования .

Таким образом, никакие другие ресурсы или клиенты не могут получить доступ к C Api. Ресурс знает, какой клиент сделал вызов, и точно знает, что это от имени пользователя, которого они говорят, поскольку это является частью токена доступа и может быть проверено (самоанализом) IdentityServer.

Answer 2

Аутентификация должна быть реализована для всех сервисов, независимо от того, предоставляется ли она пользователю или нет.

Если сервис действует от имени пользователя, как в синхронном запросе от пользовательского интерфейса, касающемся как A, так иC в вашем примере используйте поток кода авторизации OAuth2, где тот же токен будет проходить через A к C.

Если служба НЕ действует от имени пользователя, как в пакетном задании или потребителе потоковой передачиплатформу, используйте клиентский поток OAuth2, где C (в вашем примере) получит свой собственный токен с сервера авторизации.

Оставление микросервиса открытым без какой-либо аутентификации от клиента не защищено независимо от того, как оно используется и гдеон расположен в потоке вызовов.