#authentication #microservices
Вопрос:
Допустим, у меня есть 2 микросервиса (клиент и оплата), оба используют API внешней системы (например, Stripe).
Аутентификация по API
- Предположим, что перед использованием любого бизнес-API Stripe Потребитель API (в моем случае Клиент и платежная служба) должен сначала пройти аутентификацию с использованием ключей API (AppID и secret).
- Stripe предоставляет маркер доступа, который должен быть передан в HTTP-заголовок при последующих вызовах API Stripe.
ниже могут быть возможные подходы,
Подход1 https://drive.google.com/file/d/1BGn-hiNwZT4u3BIBmEv-HkJC0w0dk5CB/view?usp=sharing
Подход2: https://drive.google.com/file/d/1JA1hFq7l7-4Ow3b32XNyb2co4tqxKZQ6/view?usp=sharing
Подход1
- Несколько токенов аутентификации, хотя учетная запись Stripe одна (для каждого экземпляра службы)
- Каждая служба для управления истечением/обновлением токена аутентификации
Подход2
- Единый токен аутентификации существует для всех сервисов.
- зависимость от службы аутентификации.
- срок действия/продление токена аутентификации управляется одной службой (Служба аутентификации)
хотели бы знать, что лучше всего подходит для архитектуры микросервиса? Есть еще какие-нибудь предложения?
Ответ №1:
Подход 2 немного более масштабируем и удобен в обслуживании, если для большего количества служб потребуется доступ API к внешним API. Однако правильной реализацией был бы выходной шлюз для всех ваших внешних вызовов API. Если вы собираетесь потратить время на создание службы аутентификации, вы также можете пройти весь путь и централизовать свою внешнюю маршрутизацию API. Преимущества:
- Единая внутренняя конечная точка для внешних API уменьшает дублирование.
- Обрабатывает все authn и authz с помощью внешних API для ваших служб.
- Централизует все ведение журнала, аудит, аварийное восстановление, балансировку нагрузки и т.д….
Большинство продуктов шлюза, таких как kong, также можно использовать для выхода.