Авторизация в API Gateway против конечных точек микросервиса

Question

Я пытаюсь построить микросервисную архитектуру. Я узнал о некоторых преимуществах API-шлюза, таких как: балансировка нагрузки, вызов нескольких микросервисов и агрегирование результатов, управление кэшем и т. Д. Поэтому я решил включить его в свою систему.

У меня вопрос, могу ли я следует ли осуществлять авторизацию на уровне шлюза или отдельно в каждой конечной точке микросервиса ? Например, аутентификация пользователя на шлюзе и передача пользовательских утверждений в расшифрованном виде для использования в логике авторизации для каждого вызова службы?

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

Какой ваш совет?

Answer 1

Вы можете использовать API Gateway Pattern / API Gateway. Затем вы также можете снять ответственность за аутентификацию / авторизацию микросервиса. Это будет легко для пользователя или разработчика, который вызывает сервисы. API GW поддерживает даже External / Internal GW. Может поддерживать разрешения базы ролей. например: WSO2 APIM.

При использовании API / MS GW вы получите следующие преимущества: - Шлюз API является единственной точкой входа для любых вызовов микросервисов. - Он может работать в качестве прокси-службы для направления запроса в соответствующий микросервис. - Он может агрегировать результаты для отправки обратно потребителю. - Это решение может создать детализированный API для каждого конкретного типа клиента. - Он также может конвертировать запрос протокола и ответить.

Answer 2

каждая конечная точка микросервиса. Реализация авторизации в API-шлюзе сделает вашу систему жесткой. Если на любом последующем этапе вам необходимо разделить логику авторизации (скажем, внутренний пользователь, внешний пользователь, открыть API). Это будет очень сложно включить. Авторизация должна происходить на каждом уровне API.