Как обрабатывать аутентификацию пользователей с помощью микросервисов в AWS?

Во-первых, для решения этой общей проблемы существует несколько подходов.

Вот один популярный вариант:

Разделите свой мир на аутентификацию (вы тот, кем вы себя называете) и авторизацию (вам разрешено делать это действие).

Как правило, каждая служба сама решает вопрос об авторизации. Оставьте аутентификацию для одной точки в системе - шлюза аутентификации - обычно объединенного внутри шлюза API.

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

Реализация может быть выполнена несколькими способами. JWT - один из таких методов.

Аутентификатор создает JWT после получения правильных учетных данных, и клиент использует этот JWT в каждом запросе к каждой службе.

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

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

Важно централизовать аутентификацию даже при использовании микросервисов для одного продукта. Итак, я предполагаю, что вы будете искать службу идентификации (служба аутентификации), которая будет обрабатывать аутентификацию и выдавать токен. Другие микросервисы будут действовать как поставщики услуг, которые будут проверять выданный токен.

Примечание. В таких стандартах, как OpenID connect, выданный id_token имеет формат JWT, который также не имеет состояния и является самодостаточным с записанной информацией о пользователе. Таким образом, отдельные микросервисы не должны связываться со службой аутентификации для каждой проверки токена. Однако вы можете рассмотреть возможность внедрения или использования токенов обновления для обновления токенов, не требуя от пользователей повторного входа в систему.

В зависимости от выбранной вами технологии изменится характер выпуска и проверки токенов.

e.g:

• Платформа ExpressJS для серверной части. Вы можете проверить токены и маршруты в обработчике промежуточного программного обеспечения узла, используя Passport.
• Если вы используете API-шлюз перед конечными точками микросервисов, вы можете использовать Custom Authorizer Lambda для проверки токенов.

Однако рекомендуется использовать стандартный протокол, такой как OpenID connect, чтобы в будущем вы могли быть совместимы с Identity Federation и SSO.

Поскольку вы упомянули, что надеетесь найти собственное решение, оно также сопряжено с некоторыми проблемами, которые необходимо решить,

• Политики паролей
• Поддерживаемые стандарты (OpenID Connect)
• Безопасность (шифрование в состоянии покоя и при передаче, особенно для PID)
• SSO, MFA, поддержка Федерации и т. Д.
• IDS / IPS

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

Вот почему большинство людей рекомендуют использовать сервер идентификации или сервис, такой как Cognito, Auth0 и т. Д., Чтобы повысить рентабельность инвестиций.