распространение маркера доступа между микросервисами

#spring-security #oauth-2.0 #microservices #spring-security-oauth2

Вопрос:

Я работаю над приложением для микрослужб, в котором клиентское приложение отправляет access token orders микрослужбу с POST вызовом. При сохранении заказа следует вызвать микрослужбу инвентаризации, чтобы обновить запасы. Метод микросервиса инвентаризации updateIntentory также должен быть защищен.

В этом случае использования я должен распространить то же access token самое inventory на микросервису и ограничить доступ к api для обновления инвентаризации или я должен использовать поток client-credentials предоставления, чтобы разрешить saveOrder методу в order микросервисе вызывать updateInventory метод в inventory microservice .

Примечание order . И микросервисы, и inventory микросервисы действуют как серверы ресурсов. Каков правильный подход?

Комментарии:

1. Я думаю, что вы описываете то, что службы orders и inventory действуют как сервер ресурсов . Если orders служба вызывает inventory , вы можете реализовать шаблон ретрансляции токенов или использовать client_credentials его отдельно client_id , в зависимости от того, используют ли две службы одну и ту же схему авторизации или нет.

2. @SteveRiesenberg Микросервисы заказа и инвентаризации действуют как серверы ресурсов. Как реализовать token-relay шаблон? Кроме того, что такое authorization scheme

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

4. @SteveRiesenberg Я не нашел никакого практического руководства и поэтому спросил в комментарии.

5. Под «схемой авторизации» я просто подразумеваю требования вашего приложения к авторизации. Например, если обе службы требуют ROLE_USER выполнения требуемой операции, в отличие от одной, требующей совершенно другого уровня доступа от другой; другим примером может быть то, определяете ли вы, к чему пользователь имеет доступ одинаковым образом между двумя службами, или очень разными способами.

Ответ №1:

Хороший вопрос:

границы

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

МИКРОСЕРВИСЫ

Если владелец данных тот же, то вам следует просто переслать маркер доступа. Вот как должен работать OAuth: масштабируемая архитектура, требующая только простого кода:

  • Клиент получает маркер доступа с областями действия для нескольких API
  • Каждый API проверяет JWT
  • Каждый API проверяет свои собственные области
  • Каждый API доверяет утверждениям в JWT и использует их для авторизации

В статье «Лучшие практики в области применения» объясняется это для системы реального мира.

ОПЕРАЦИИ С ВЫСОКИМИ ПРИВИЛЕГИЯМИ

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

Комментарии:

1. Как распространить токен с одного микросервиса на другой? Существует ли стандартный способ, так OAuth2RestTemplate как он устарел в Spring Boot.

2. Просто по простому HTTP — запросу-например, используйте HTTP-клиент Apache. Все, что вам нужно сделать, это отправить токен на предъявителя в заголовке авторизации HTTP — избегайте безопасности Spring для простых вызовов API. См. Это руководство