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

Question

[razer96]

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

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

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

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

Буду очень рад любому совету от знающего человека, так как сам профан в построении микросервисной архитектуры, и это мой первый опыт).

Answer 1

[Artem Levenkov]

Позднова-то наверное, но лучше поздно, чем никогда.

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

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...

Comments

[Александр Гамов]

Спасибо тебе, добрый человек.

Answer 2

[abmanimenja]

Всякие oAuth 2.0 придуманы как раз для этой цели.
https://habr.com/ru/company/mailru/blog/115163/
Другое дело, что их используют не по назначению и в более мелких проектах.
Но основной смысл как раз в том, что аутентификация идет отдельным, независимым от вашего микросервиса образом.

Я бы не грел голову а взял бы готовый шлюз API
https://konghq.com/faqs/

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

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

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

Comments

[razer96]

А как в таком случае должна происходить валидация JWT? Я не подразумеваю авторизацию через OAuth.

[abmanimenja]

razer96,

А как в таком случае должна происходить валидация JWT?

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

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

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

[razer96]

abmanimenja, хмм, спасибо за информацию, очень помогло.

[razer96]

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

[abmanimenja]

razer96, преимущество в том что уже готовый и многофункциональный и опробированный на больших нагрузках.

[razer96]

abmanimenja, Подскажите, а что думаете насчет Express-Gateway? Подойдет как аналог Конгу?

Answer 3

[rPman]

Зачем на каждый запрос спрашивать валидность токена у самого главного?

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

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

Токен - абстрактно это уникальный код плюс параметры авторизации - время действия и права доступа

Comments

[razer96]

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

[rPman]

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

[razer96]

rPman, Интересно, спасибо большое. Тогда могу еще вопрос задать касательно токена. Можно ли создавать токен без времени жизни? Просто мне кажется для мобильных систем это актуально. Или же как делать? Генерить два токена, например access токен и refresh токен. И при истечении время жизни access токена, при авторизации просто отправлять refresh токен? Но рефреш токен же тоже имеет свое время жизни? Как в мобильных приложениях обойти проблему истечения время жизни токена, чтобы была беспрерывная авторизация?

[rPman]

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

Answer 4

[DenisPotekhin]

А где должны хранить этот валидный токен сервисы?
И у клиента токен хранится как я понимаю, в памяти клиентского приложения?
Я сейчас про access-token..