Общее промежуточное ПО против API аутентификации

Question

Я работаю над потоком входа в систему и не могу решить, что лучше для проверки аутентификации в микросервисной архитектуре.

Что происходит, так это то, что jwt отправляется клиенту в httpOnly cook ie, где он остается при входе в систему.
При каждом запросе cook ie отправляется защищенным API REST (микросервисам) для проверки подлинности запроса / JWT.

Доступны две опции:

• Я создаю общее промежуточное ПО для проверки повара ie / jwt и добавляю его в каждый микросервис
• Я встраиваю эту службу в авторизировать микросервис и создавать запросы для централизованной обработки проверки через http (s).

Оба варианта сработают, мне интересно, каковы плюсы и минусы каждого подхода.
У вас есть опыт работы с одним из них и, следовательно, вы предлагаете один над другим?

Answer 1

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

Http-вызовы создают очень небольшую задержку, но опять же http-вызовы облегчаются.
То же самое относится и к микросервисам, которые взаимодействуют друг с другом, кроме аутентификации.
Они будут загружены в Скопление Kubernetes в облаке, я предполагаю, что эти звонки будут быстрыми.

Код все еще может быть изменен в случае необходимости.