Микросервисная архитектура аутентификации / авторизации

Question

АРХИТЕКТУРА

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

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

Есть ли способ сделать это?Или мне нужно заново создать пользовательскую таблицу в каждом микросервисе?В основном это означает, что каждый раз, когда пользователь хочет получить доступ к микросервису, я должен создать нового пользователя (POST из основного API) в микросервисе (при потере целостности данных).

Я еще ничего не пробовал, глядядля предложений / надежной и безопасной архитектуры.Каждый микросервис будет размещаться на поддомене в том же PAAS, чтобы избежать атак передачи и уменьшить задержку.

Answer 1

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

Предполагается, что вы используете OAuth2.0 с JWT доступом и обновлением токенов вы можете использовать утверждение aud для токена JWT для передачи полномочий, разрешений или разрешений для доступа к отдельным микросервисам.В утверждении "aud" вы можете указать отдельный URL-адрес службы или идентификатор службы, к которым у пользователя есть права доступа.В отдельном микросервисе (или сервере ресурсов в терминологии OAuth) вам необходимо проверить, несет ли JWT конкретный UR или идентификатор микросервиса в своем утверждении "aud".В противном случае доступ будет запрещен.

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

Обычно это не такготово.

У вас обычно есть сервер авторизации.Это мастер всей пользовательской информации.Любой неаутентифицированный пользователь, пытающийся получить доступ к какой-либо службе, будет перенаправлен на сервер авторизации, и ему будет предложено предоставить свои авторизации после аутентификации.После того, как аутентификация выполнена и авторизация предоставлена, пользователь будет перенаправлен на страницу сервиса с соответствующими маркерами доступа и обновления, которые впоследствии будут сопровождать все пользовательские запросы.Даже когда запрос идет от User A -> Service B -> Service C.Затем службы B и C должны будут проверить:

1. Является ли JWT действительным (никто не вмешивался)?(с использованием цифровой подписи в JWT - обычно HMACSHA256)
2. Является ли токен доступа (обычно JWT) все еще действительным в соответствии с датой и временем истечения, установленными в требовании "exp" JWT сервером авторизации?
3. Присутствует ли URL-адрес или идентификатор службы в заявке "aud"?

Если на все 3 вопроса дан ответ "да", доступ предоставляется, и каждая служба может найтиимя пользователя из претензии "sub" JWT.Имя пользователя может быть зарегистрировано для аудита

Я также рекомендую прочитать этот ответ .