
Коллеги, приветствую!
Есть интересный вопрос про внедрение IdentityService4 в "микросервисную" архитектуру.
У нас есть Ui React, страницы которого защищены Identity, используется authorization_code flow для получения access_token.
Скоупами в данном случае являются openid profile и cms_service
После его получения мы обращаемся с ним к cms_service, который в свою очередь запускает цепочку вызовов других сервисов для получения данных
К примеру цепочка такая
ui ==> cms_service ==> business_service ==> data_service
так вот, если мы получаем токен только для cms_service с ним мы уже не можем обращаться к business_service, поэтому была идея настроить взаимодействие между cms и business через M2M с помощью client_credentials flow, но при таком потоке мы не получаем данные о авторизованном пользователе, а эти данные необходимы в data_service....
и вот вопрос, есть ли какие-то "лучшие практики" для создания подобного рода взаимодействия?
примерное графическое представление цепочки действий во вложении
Просто -- приложите идентити юзера в заголовках и рассчитываете, что все сервисы друг другу доверяют (либо защищённая сеть, либо по MTLS, либо по client_credentials). Сложно -- почитайте про OAuth Token Excnahge (это пока draft, но уже почти стандарт) и пусть каждый промежуточный сервис на основе полученного токена запрашивает новый для доступа к следующему сервису. Однако при значимой нагрузке AS становится точкой отказа. Ибо если даже access_token является JWT, и его можно проверить без обращения к AS, то для выписки новых токенов нужен запрос в AS, что довольно накладно. Плюс менджмент этих токенов со стороны каждого сервиса (не на каждый же апи запрос получать новый "промежуточный" токен)