Микросервис: лучшие практики для аутентификации

Question

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

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

Answer 1

Хотя ответ Аннуная является одним из самых известных решений, есть еще одно решение, на которое я хотел бы обратить вниманиеВы можете использовать некоторые распределенные системы управления сеансами для сохранения сеансов на RAM или DISK.Например, у нас есть модуль аутентификации, который создает токен и сохраняет его в Redis.Несмотря на то, что сам Redis может распространяться и может сохранять менее использованные данные на диске, для всех микросервисов будет хорошим выбором проверить клиентские токены с помощью redis.

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

Внутри сеанса вы можете хранить роли и разрешения пользователей.Таким образом, вы можете получить строгий доступ пользователей к некоторым API.А для ваших частных API вы можете сгенерировать токен с ролью ADMIN.Затем каждый микросервис может вызывать другой с этим токеном, чтобы ваши API были в безопасности.

Также вы можете быстро аннулировать любые сеансы и сохранять все, что вы хотите в этих сеансах.В нашей системе Spring Framework генерирует X-AUTH-TOKEN, который может быть установлен в заголовках.Маркер указывает на ключ сеанса в redis.Это работает с Cookies тоже. (и если я не ошибаюсь, вы могли бы даже использовать этот метод с oAuth и JWT)

В чистой архитектуре вы можете создать модуль безопасности, который использует эту проверкуметод через API и добавьте его в каждый микросервис, который вы хотите защитить.

Существуют и другие варианты, когда речь идет о продолжении сеанса тоже.База данных, LDAP, Redis, Hazelcast ... выбор зависит от ваших потребностей.

Answer 2

Вы можете выполнить аутентификацию на уровне шлюза, если аутентификация - это все, что вам нужно.Если вы заинтересованы в авторизации, вам может потребоваться передать токены для подачи заявки на рассмотрение.Также вы можете сделать это, если у вас есть доверие к другим службам за шлюзами.То есть служба 1 может бесплатно вызывать службу 2 без аутентификации.Кроме того, вы теряете немного информации о принципале, однако можете переслать ее обратно по запросу в шлюзе при пересылке.

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

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