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

Question

У меня есть:

• myApp (сервер 1)
• микросервис аутентификации пользователя + база данных пользователей (сервер 2)

микросервис аутентификации пользователя имеет REST API, с помощью которого я могу управлять пользователями (создавать / удалять пользователей, обновлять данные пользователей, получать список всех пользователей, проверять пароль пользователя и т. д. c.)

Теперь мне нужно реализовать авторизацию / аутентификация:

• между пользователем и myApp (для этого я собираюсь использовать обычные сеансы (файлы cookie, содержащие только идентификатор сеанса) и хранить данные сеанса в Redis)
• между myApp и микросервисом аутентификации пользователя (для этого я предполагаю, что мне нужно использовать какой-то ключ API / токен)

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

На прошлой неделе я много читал об авторизации / аутентификации в REST API, но до сих пор не могу понять , как создать а * 11 21 * система авторизации / аутентификации для пользователя -> myApp и myApp -> микросервис аутентификации пользователя .

Вот что я придумал с на данный момент.

Зарегистрироваться ( Диаграмма ):

1. Пользователь регистрируется, отправляя имя пользователя / пароль / другие данные в myApp
2. myApp отправляет имя пользователя / пароль / другие данные в микросервис аутентификации пользователя
3. Микросервис аутентификации пользователя создает нового пользователя в базе данных пользователей

Войти ( Диаграмма ):

1. Теперь пользователь подписывается, отправляя имя пользователя / пароль в myApp
2. myApp отправляет имя пользователя / пароль в микросервис аутентификации пользователя, который проверяет имя пользователя / пароль
3. Если имя пользователя и пароль верны, микрослужба аутентификации пользователя генерирует ключ API (случайную строку) и сохраняет его в базе данных пользователей, связывая этот ключ API с записью пользователя:

   username | password | email | address | APIKEY
   ---------+----------+-------+---------+-----------
   steve    | n8Y5e... | ...   | ...     | D4ED43...   
   

4. Затем микросерви для аутентификации пользователя ce возвращает сохраненный ключ API (+ некоторую дополнительную информацию о пользователе, которому он принадлежит) myApp
5. myApp создает новый сеанс, сохраняя его в Redis: генерирует идентификатор сеанса и сохраняет идентификатор сеанса + ключ API + другие данные сеанса в Redis:

   sessionID: 9w72tv3MHZD...
   
   session_data: {
     "cookie": {
       "originalMaxAge": ...,
       "expires": ...,
       "httpOnly":true,
       "path": ...
     },
   
     "user": {
       "authenticated": true,
       "username":"steve",
       "apiKey": D4ED43C0...,        
       "created": ...
     }
   }
   
   expire: ...
   

6. Наконец, сервер myApp отправляет ответ с кодом ie, содержащим идентификатор сеанса.
7. Готово, пользователь вошел в систему.

При каждом последующем запросе ( Диаграмма ):

1. Пользователь отправляет повара ie, содержащего идентификатор сеанса
2. Сервер myApp сравнивает идентификатор сеанса с тот, который хранится в Redis.
3. Если они совпадают, myApp снова просматривает данные сеанса, извлекает ключ API, связанный с идентификатором сеанса, и отправляет этот ключ API в микросервис аутентификации пользователя
4. User- Микрослужба проверки подлинности ищет пользователя в базе данных пользователей по ключу API. Если предоставленный ключ API существует, это означает, что пользователь, связанный с этим ключом API, аутентифицирован.
5. Микрослужба аутентификации пользователя предоставляет доступ, возвращая что-то вроде { authenticated: true, username: "steve" } в myApp
6. myApp использует это ответ на предоставление / ограничение доступа к страницам / функциям приложения

Выйти ( Диаграмма ) (первые 4 шага в точности такие же, как в «По каждому последующий запрос »выше):

1. Пользователь отправляет повар ie, содержащий идентификатор сеанса
2. Сервер myApp сравнивает идентификатор сеанса с тем, который хранится в Redis.
3. Если они совпадают, myApp снова просматривает данные сеанса, извлекает ключ API, связанный с идентификатором сеанса, и отправляет этот ключ API в микросервис аутентификации пользователя
4. Микросервис аутентификации пользователя ищет пользователя в базе данных пользователей по ключу API . Если предоставленный ключ API существует, это означает, что пользователь, связанный с этим ключом API, аутентифицирован.
5. Микрослужба аутентификации пользователя удаляет ключи API из базы данных пользователей и отвечает примерно { authenticated: false } на myApp
6. myApp видит, что пользователь не аутентифицирован, и удаляет все данные сеанса из Redis.
7. myApp также «удаляет» ie Cook, устанавливая дату истечения срока его действия в прошлом, и пользователь выходит из системы.

Вопрос: Я что делаю не так? Что мне изменить? Я никогда раньше не создавал аутентификацию для API, поэтому буду признателен за любые рекомендации. Я хочу понять «общую картину».

Answer 1

Вы должны использовать аутентификацию на основе токенов. Ваш поток должен быть таким:

1- Пользователь зарегистрируется в вашем микросервисе аутентификации.

2- Пользователь отправит имя пользователя и пароль в микросервис аутентификации и получит токен-носитель.

3- Пользователь отправляет полученный токен носителя на все конечные точки (apis), и каждый микросервис должен аутентифицировать пользователя с помощью этого токена.

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