Авторизация пользователя в Api Gateway
Я пытаюсь понять архитектуру микросервисов, и у меня есть вопрос о том, как правильно авторизовать пользователя в Api Gateway или проверить его существование, если у меня есть отдельный микросервис пользователей для регистрации, входа в систему и выпуска токенов. Допустим, у меня есть два микросервиса: юзер сервис для регистрации, входа в систему и получения токенов и сервис заказов. У них есть свои базы данных. Также есть Api Gateway, который сейчас просто делает перенаправление.
У меня есть предположения:
- Для каждого запроса к шлюзу api делать отдельный запрос к юзер сервису и проверять там токен и роль пользователя, и только потом перенаправлять запрос в сервис заказа.
- Предоставить шлюзу Api доступ к базе данных пользователей для проверки токена и пользователя, а затем перенаправить запрос в службу заказа.
- Объединить Api Gateway и юзер сервис (думаю, это плохая идея). Или есть догадки получше?
Ответы (1 шт):
Cтандартный способ решения проблемы "как не лезть в базу" - использование двух токенов (как в oauth2) - access token + refresh token.
Выделяете авторизационный сервис. Он должен в обмен на username / password выдавать два токена
Access Token - подписанный json (JWT), короткоживущий (минут 10), со вшитым временем действия. Он передается на каждом запросе. Для его проверки не нужно лезть в базу, достаточно провеки подписи и времени действия. Готовые API Gateway (Ocelot, Envoy) умеют проверять JWT, доставать из него атрибуты (id пользователя, роль, флаги доступа к определенным фичам, что угодно) и прокидывать их параметрами в микросервисы.
Refresh Token - хранится на стороне клиента, и на стороне авторизационного сервиса (в базе). При истечении Access Token (или близко к истичению) клиент может полезть с refresh token в авторизационный сервис и получить новый Access Token.
Вылогинивание пользователя в этой схеме - это удаление Refresh Token из базы авторизационного сервиса. Клиент просто не сможет получить новый Access Token. Время жизни Access Token подбирается под конкретные условия. Если это защита от кражи девайса - до минут 15 достаточно.