Как вы справляетесь с авторизацией и аутентификацией i Microservices? - PullRequest
Новая
       77

Как вы справляетесь с авторизацией и аутентификацией i Microservices?

3 голосов
/ 21 марта 2019

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

Позвольте мне объяснить, как работает решение: пользователь может иметь разные роли в разных отделах, а количество отделов может превышать 200. В каждом отделе пользователь может иметь несколько ролей. Мы понимаем, что рекомендуемый способ обработки ролей - поместить их в маркер, отправленный с клиента на сервер (JWT). Но мы обеспокоены тем, что это сделает полезную нагрузку токена слишком большой. Насколько я знаю, браузер может хранить заголовки до 5 КБ данных. В нашем случае это около 50 отделений с двумя ролями (без сжатия). Преимущества такого подхода заключаются в том, что пользователь авторизуется и аутентифицируется при входе в микросервис. Как я уже говорил, минусы - большая полезная нагрузка в токене.

Мы также рассматриваем другой вариант, в котором мы сводим JWT к минимуму (userid и detamentid) и запрашиваем Keycloak для получения прав пользователя при каждом запросе (возможно, добавьте некоторый механизм кэширования с коротким сроком службы). Этот подход будет генерировать много запросов к серверу авторизации.

Что я ищу, так это какой-то совет / опыт того, как другие решили это. Я рад предоставить больше информации, если это необходимо.

Чтобы вам было легче давать советы, вот краткое описание двух вариантов: 1) Использовать JWT для обработки аутентификации и авторизации? Зачем? 2) Поддерживать JWT и делать запросы на сервер авторизации в каждом микросервисе? Почему?

1 Ответ

0 голосов
/ 21 марта 2019

Я бы сказал, два варианта:

Вариант 1

  1. Держите свет JWT
  2. Используйте тип предоставления OAuth2 "Код авторизации" с токеном обновления и токеном доступа
  3. Кэшируйте права пользователя в централизованной распределенной системе кеширования с помощью политики исключения, такой как LFU
  4. Во время обновления токена доступа (что будет происходить периодически в зависимости от срока действия токена доступа), получите последние права доступа пользователя и обновите кеш
  5. Если права доступа не доступны в кеше, запросите Keycloak и добавьте записи в кеш

Таким образом,

  1. Любое изменение прав потребует периода действия токена для отражения
  2. Производительность будет лучше благодаря кешированию

Вариант 2

То же, что и в варианте 1, за исключением того, что вы можете использовать сбор данных изменений (CDC) в базе данных привилегий пользователя, чтобы обновлять кэш при любых изменениях прав доступа.

...