Запрос токена доступа для второго API, который требует шага согласия

Question

В настоящее время разрабатывается React SPA с различными вызовами API. В итоге у меня появился User Experience API , который обрабатывает различные вызовы для других API в фоновом режиме с их токенами доступа, которые UX API запрашивает от oauth2/v2.0/token конечной точки. Приложение использует OBO - от имени - flow, объясненного в следующей статье:
Платформа идентификации Microsoft и OAuth 2.0 On-Behalf-Of .

Для моего веб-приложения, размещенного в Azure, имеется следующая архитектура упрощенная :

Код и проблемы:

Итак, в UX API - это Azure Функция v2.0 - я пытаюсь чтобы получить токен доступа для других Data 2 API - см. выше архитектуру - на основе шагов, описанных в упомянутой документации Microsoft.

Объяснение сценария :

1. Сначала пользователь открывает приложение, затем ему необходимо дать согласие на авторизацию для UX API ,
2. Затем при успешном входе в систему приходит токен доступа, который можно использовать для вызова UX API ,
3. В UX API запрашивается токен доступа для Da ta 2 API - см. реализацию кода ниже,
4. Ответ приходит, когда пользователь должен дать согласие на авторизацию для Data 2 API .

См. ниже реализации кода, которая, кажется, работает нормально:

const {authorization} = context.bindings.req.headers;
const config = {
   method: 'post',
   url: 'https://login.microsoftonline.com/<our-tenant-id>/oauth2/v2.0/token',
   headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
   data: qs.stringify({
      'scope': 'https://<data-2-api-resource-url>/access_as_user',
      'client_id': '<application client id>',
      'client_secret': '<app-client-secret>',
      'grant_type': 'urn:ietf:params:oauth:grant-type:jwt-bearer',
      'requested_token_use': 'on_behalf_of',
      'assertion': authorization.replace('Bearer ', '')
   }),
   httpsAgent: agent
};

const res = await axios(config);
const accessToken = res.data.access_token;

, которая выбрасывает следующее исключение в фоновом режиме :

AADSTS65001: пользователь или администратор не дал согласие на использование приложения с идентификатором '<app-client-id>' с именем '<app-name>'. Отправьте интерактивный запрос авторизации для этого пользователя и ресурса.

Вопросы:

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

Итак, мой вопрос, как мне поступить со сценарием? Ниже приведены мои предположения о том, что может быть неверным:

1. Не следует ли каким-либо образом обрабатывать в конфигурации приложения, которые, если действительный токен доступа поступает из UX API , не требуют дальнейшего согласия?
2. Отправьте обратно пользователю окно взаимодействия, чтобы получить согласие на авторизацию для Data 2 API , который не является отличным UX для конечного пользователя.
3. Измените каким-либо образом весь поток авторизации от имени пользователя?

Не уверен, я ценю любую помощь!

Answer 1

В разделе «Expose a API» для регистрации приложений есть раздел авторизованных приложений. Там вы можете указать, какие приложения могут использовать какие области. Другой вариант, который может сработать, - это массив knownClientApplications в манифесте приложения API. Вы можете добавить идентификатор клиента интерфейсного приложения, чтобы сделать одновременное согласие.

Answer 2

Приятно видеть, что это сработало - отличная штука для вас обоих! Разрешение пользователю войти в систему один раз, а затем получить доступ к нескольким связанным ресурсам, является распространенным требованием.

Вышеупомянутое решение выглядит намного лучше, чем заставить пользовательский интерфейс выполнять перенаправления без вывода сообщений для каждого ресурса - что особенно трудно для SPA из-за использования из фреймов.