#c# #asp.net-core #.net-core #authorization #microservices
#c# #asp.net-ядро #.net-ядро #авторизация #микросервисы
Вопрос:
Я решил впервые попробовать реализовать микросервисную архитектуру вместо монолитной и столкнулся с проблемой авторизации. В монолитной архитектуре я просто передавал токен в заголовке при доступе к контроллеру, на котором висел атрибут [Authorize], и сверял его с текущей единой базой данных. Но в микросервисной архитектуре у каждого микросервиса есть своя база данных, как вы можете проверять токен при доступе к другим микросервисам, я слышал о реализации проверки в API Gateway, но я думаю, что, в любом случае, у каждого микросервиса должна быть своя проверка, поскольку, не должно быть доступа кapi, если пользователь не авторизован. Должен ли я использовать api gateway для отправки запроса к микросервису авторизации для проверки? Как я могу это реализовать?
У меня есть отдельный микросервис для авторизации пользователей (регистрация, вход в систему, выдача токенов), который имеет базу данных пользователей с токенами. То есть мне нужно сделать запрос к этому микросервису с помощью API Gateway?
Ответ №1:
Один из способов — вы должны попытаться выполнить аутентификацию / авторизацию на уровне шлюза API. Всякий раз, когда какой-либо вызов API поступает на шлюз API, которому требуется некоторое разрешение, проверьте токен. Если доступ / токен отсутствует, верните 401. В интерфейсе, если вы получаете 401, выполните аутентификацию в пользовательском интерфейсе.
2-й способ — пользовательский интерфейс передает токен шлюзу API, который в дальнейшем отправляет токен другим микросервисам.
Это зависит от того, какой уровень разрешения вам нужен. Если он находится на очень высоком уровне зернистости, тогда идите со 2-го, иначе идите с 1-го.
Комментарии:
1. У меня есть отдельный микросервис для авторизации пользователей (регистрация, вход в систему, выдача токенов), в котором есть база данных пользователей с токенами. То есть мне нужно сделать запрос к этому микросервису, используя API Gateway, или что?
2. Всякий раз, когда пользовательский интерфейс взаимодействует с любым другим микросервисом, отличным от службы авторизации, он должен проходить через шлюз API, а шлюз API должен использовать службу авторизации для проверки токена. (1-й подход лучше)
3. Хорошо, спасибо за объяснение, но меня беспокоит одна вещь, оказывается, мне нужно сделать api микросервисов полностью доступными, чтобы api gateway мог ссылаться на них после проверки, но если кто-то попытается напрямую получить доступ к api микросервиса в обход api Gateway, как ограничитьДоступ?
4. Предоставьте общедоступный IP или DNS только для шлюза API. Все остальные службы должны иметь только частный IP. Мы сделали то же самое в одном из моих проектов, где мы использовали Kubernetes, а NGINX был доступен извне и перенаправлял трафик на шлюз только в стороне от Kubernetes.
5. Для вашей справки — github.com/dotnet-architecture/eShopOnContainers — «Это очень хороший пример реализации микросервиса в .NET.