#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. См. Это руководство