Как аутентифицироваться и авторизоваться в микросервисной архитектуре
Короткий: Как аутентифицировать и авторизовать пользователей на основе ролей в микросервисной архитектуре?
Длинный: Скажите, что у вас есть архитектура, представленная ниже. Я изо всех сил пытаюсь понять, что было бы лучшим практическим решением для защиты такой архитектуры. Когда я ищу, я получаю много разных ответов.
«Оставьте аутентификацию стороннему провайдеру OAuth». Это похоже на добавление большого количества накладных расходов и сложности для довольно простого приложения, и может быть нежелательно делегировать аутентификацию и авторизацию третьей стороне.
"Использовать JWT". Если я прав, то использование токена JWT не подходит для внешнего использования (например, в SPA).
«Использовать комбинацию непрозрачных токенов извне и JWT, внутренне связанного в redis / memchache». Это кажется лучшим решением для моей ситуации, но моя проблема здесь в отсутствии реальных ссылок на библиотеки / примеры кода.
Я был бы очень признателен, если бы у кого-то были ссылки на фактические реализации того, что я пытаюсь выполнить, а именно: Аутентификация, авторизация на основе ролей, в микросервисной архитектуре.
Ответы 1
Недостаточно информации, чтобы предложить, что именно вы должны делать с архитектурой аутентификации и авторизации, но я могу сказать вам один из подходов, на которые я обычно полагаюсь.
Следуйте протоколу OAuth, так как он дает вам довольно много возможностей: вы можете начать с собственного IDM / IAM, а затем сможете подключаться через социальные платформы.
Мы начали с JWT, и по большей части это был просто подписанный токен (через некоторое время мы перешли на подписанные и зашифрованные токены). Мы создали одну службу, отвечающую за обработку аутентификации и создание токена JWT. (Мы начали с Keycloak, но позже перешли на собственный сервис, так как keycloak был слишком громоздким для нашего варианта использования)
Когда вы говорите внешний, я не уверен, что вы имеете в виду, если он доступен конечному пользователю IMO, мы можем жить только с подписанным токеном. Да, вся информация видна пользователю, но это вся его информация и некоторая информация, относящаяся к авторизации.
Если вы передаете свой токен кому-то за пределами ваших границ, в реальную внешнюю систему, где вы не хотите делиться информацией об использовании, вы можете подумать о ее шифровании, но тогда вам придется подумать о многих вещах, связанных с безопасностью. Перспективы и, следовательно, выбор либо стандартной платформы безопасности, либо стороннего поставщика (которому вы оба можете доверять и который уделяет достаточно внимания ее защите), может помочь вам в долгосрочной перспективе.
Использование комбинации непрозрачного токена и JWT может быть излишним, если только у вас нет очень веских причин против этого. ИМО, вы сохраняете простоту для начала, используйте JWT, если требуется, зашифруйте его. Все, что вам нужно, это еще одна служба для управления аутентификацией, создания и подписания токена, и у вас все должно быть хорошо.
Как и ваши проблемы с безопасностью, если вы создаете внутреннее или простое приложение для электронной коммерции, jwt может помочь вам, однако, если вы работаете с такими вещами, как кошельки и тому подобное, токены могут быть недостаточно безопасными. С помощью микросервисов и разделения задач вы можете написать развивающуюся архитектуру, которая может развиваться довольно легко.
Ответственность за это решение будет возложена на общедоступный SPA, предоставляемый через nginx. Посредством этого SPA обычные пользователи и пользователи с «более высокими привилегиями» могут получать доступ к различным ресурсам и писать на них в зависимости от их роли. То, что я действительно ищу, - это передовой пример того, как выполнить простую аутентификацию и авторизацию по имени пользователя и паролю в среде микросервисов без необходимости полагаться на такие сервисы, как Auth0, провайдеры Google / Facebook Oauth2.
Вы можете использовать решение, размещенное в помещении, например, keycloak. Но если вы хотите написать свой собственный, из того, что я использовал, я могу предложить pac4j или shiro. Они находятся в java, но могут помочь вам понять основы. Если вам что-то нужно в узле, я, возможно, не смогу вам больше помочь, кроме как предложить вам использовать jwt libs для генерации и подписи токена и какое-то сильное решение для хеширования с солями и управление роли в простой базе данных.
Я попробую Keycloak. В противном случае я буду генерировать JWT для пользователей и хранить их информацию (имя пользователя, зашифрованный пароль и роль) в базе данных, а затем передавать jwt, содержащий их роль, что я могу проверить с помощью своих служб.
Большое спасибо за хороший ответ, Анунай. Я пока буду использовать простой JWT, чтобы посмотреть, использует ли он все, что мне нужно. Чтобы следить за вашим ответом. Какая дополнительная информация потребуется? Под внешним провайдером я подразумеваю такие услуги, как www.Auth0.com.