@razer96

Как лучше реализовать аутентификацию в микросервисной архитектуре?

Всем доброго времени суток. У меня такой вопрос, может быть кто подскажет. Проектирую микросервисную архитектуру с использованием API Gateway под каждый тип клиента, и нужен совет в плане аутентификации пользователей. Подскажите, как лучше производить аутентификацию. Поясняю: у меня есть основной REST API, который играет роль proxy сервера, ну и маршрутизатора, есть пара микросервисов( отправка email, работа с медиа, сервис работы с пользователем, и отдельно сервис авторизации). Так вот, как лучше всего сделать, чтобы было оптимально, и без оверхедов. В моем понимании есть два варианта.

Вариант 1. С клиента на API Gateway приходит какой-то запрос, например /users/updatePhoto, и в заголовках запроса содержится JWT. API Gateway посылает запрос на сервис аутентификации с вложенным токеном. Если сервис аутентификации дает положительный респонс, то запрос выполняется дальше на нужный клиенту сервис.

Вариант 2. С клиента на API Gateway приходит запрос, например на /users/updatePhoto. API Gateway сразу перенаправляет запрос на нужный микросервис, а уже в контексте каждого микросервиса будут происходить запросы на микросервис авторизации по брокеру сообщений( RabbitMQ).

Или же я вижу это все не правильно, и есть какой-то иной вариант.

Буду очень рад любому совету от знающего человека, так как сам профан в построении микросервисной архитектуры, и это мой первый опыт).
  • Вопрос задан
  • 4292 просмотра
Пригласить эксперта
Ответы на вопрос 4
Позднова-то наверное, но лучше поздно, чем никогда.

Два самых важных вопроса:

1. Каких масштабов проект? По 10-бальной шкале от 0 (интернет магазинчик) до 10 (eBay). Вангую, что не больше, чем 3-4 скорее всего.
2. Все микросервисы находятся в приватной сети или разбросаны по узлам всемирной паутины? Опять же, скорее всего первое.

Если мои предположения оказались верны, то:
1. Нафиг OAuth и прочий геморрой. Вы слишком маленькие ещё для этого, надо все делать как можно проще и конкретней. Гибкость и скорость всегда покупаются человеко-часами, чудес не бывает. Выполните основные требования сусурити (brypt, смертные токены и т.п.) и не более. Напишите что-нибудь сами, простое, понятное, и легко поддерживаемое программистами того уровня, который вы можете нанять. В 50 строк кода влезете.
2. Поставьте на входе nginx, который на каждый входящий запрос будет спрашивать подзапросом у микросервиса аутентификации: "вот запрос, такие хедеры, такой урл, кто это? его пускать?". И напишите на чем-нибудь типа Go читалку из базы юзеров, которая будет вам за 3 мс давать ответ на такой вопрос (а nginx приклеивать "Вася" к запросу и отправлять дальше или отфутболивать). А если нагрузки большой нет, то можно и медленней, не надо бояться задержки 15 мс на каждый запрос, это вполне оправданная цена за простоту и отсутствие зоопарка языков и технологий.

Вот тут я накидал очень минималистичный пример: github.com/bitia-ru/examples-microservices-authent...
Ответ написан
@abmanimenja
Всякие oAuth 2.0 придуманы как раз для этой цели.
https://habr.com/ru/company/mailru/blog/115163/
Другое дело, что их используют не по назначению и в более мелких проектах.
Но основной смысл как раз в том, что аутентификация идет отдельным, независимым от вашего микросервиса образом.
64e01804.png
Я бы не грел голову а взял бы готовый шлюз API
https://konghq.com/faqs/

запросы на микросервис авторизации по брокеру сообщений( RabbitMQ).

Вот это ни в коем случае.
Серьезно подсаживает производительность.
Зачем по вашему нужен GWT?
Чтобы избежать такого как вы описали.

Если вы хотите запрашивать все же каждый раз, то не "у сервиса аутентификации через брокер сообщений" а из какого-нибудь общего memcache/Redis/Tarantool.
Ответ написан
@rPman
Зачем на каждый запрос спрашивать валидность токена у самого главного?

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

Аналогично происходит принудительный отзыв токена (разлогиниться).

Токен - абстрактно это уникальный код плюс параметры авторизации - время действия и права доступа
Ответ написан
@DenisPotekhin
А где должны хранить этот валидный токен сервисы?
И у клиента токен хранится как я понимаю, в памяти клиентского приложения?
Я сейчас про access-token..
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы