Централизованный сервер аутентификации или один db на микросервис для пользователей?

Question

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

1. Централизованный Auth сервер, на котором будут храниться роли пользователей, а также вся информация .

2. Централизованный Auth сервер, на котором будут храниться только роли, но информация о пользователе будет храниться в базах данных их соответствующих служб (ученик, учитель)

3. Нет централизованного сервера аутентификации, но перенаправляет запрос на вход ученику или учителю в соответствии с ролью в теле запроса, и это будет ответственность шлюза.

Я хочу знать плюсы и минусы этих подходов. Если есть лучший подход, поделитесь им.

PS: - Одному пользователю можно назначить несколько ролей.

Answer 1

Я бы go за первый подход. Вместо «централизованного сервера аутентификации» это будет скорее «микросервис авторизации».

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

Я думаю, что JWT идеально подходит для микросервисов. Если вы используете сеанс, вы в основном «централизуете» свою аутентификацию и авторизацию. Я имею в виду, что после аутентификации пользователя каждый раз, когда пользователь делает запрос, все микросервисы, которые реагируют на этот ответ, должны проверять централизованный сеанс. Это не только увеличит задержку, но и будет максимально соответствовать распределенной системе. Смысл использования микросервисов в том, чтобы создавать реплики сервисов и таким образом масштабировать их по горизонтали.

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

Что касается «службы аутентификации», я бы посоветовал вам хранить только данные, связанные с аутентификацией и авторизацией (включая информацию о пользователе, связанную с аутентификацией. Номер телефона, адрес электронной почты, имя et c. вы, вероятно, будете использовать это, если пользователю нужно сменить пароль, забыть пароль и т. д. c.). Другие специфические c данные, относящиеся к определенной c роли, могут храниться в соответствующей службе.