0

現在、さまざまな API 呼び出しを使用してReact SPA を開発しています。UX APIがエンドポイントから要求しているアクセストークンを使用して、バックグラウンドで他のAPIのさまざまな呼び出しを処理するユーザーエクスペリエンスAPIを持つことになりました。アプリケーションは、記事「Microsoft ID プラットフォームと OAuth 2.0 On-Behalf-Of フロー」で説明されているOBO (代理) フローを使用しています。oauth2/v2.0/token

Azureでホストされている私の Web アプリケーションには、次の単純化されたアーキテクチャがあります。

建築

コードと問題:

したがって、Azure Function v2.0であるUX APIでは、前述の Microsoft ドキュメントで説明されている手順に基づいて、他のData 2 APIの適切なアクセス トークンを取得しようとしています。上記のアーキテクチャを参照してください。

シナリオの説明:

  1. まずユーザーがアプリケーションを開き、UX APIの承認に同意する必要があります。
  2. 次に、ログインに成功すると、 UX APIの呼び出しに使用できるアクセス トークンが到着します。
  3. Data 2 APIのアクセス トークンを要求するUX 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: ユーザーまたは管理者は、ID'<app-client-id>'という名前のアプリケーションの使用に同意していません'<app-name>'。このユーザーとリソースの対話型承認要求を送信します。

質問:

もちろん、ここで説明されている同様の問題をStackOverflowで説明していましたが、この問題はそれらとは異なると思います。彼らは 1 つのレイヤーのシナリオについて話しているだけで、エラー メッセージの意味を明確に説明しています。

だから私の質問は、シナリオにどのように対処すればよいですか? 以下の私の推測は間違っているかもしれません：

  1. 有効なアクセス トークンがUX APIから取得されている場合、それ以上の同意は必要ないアプリの構成で何らかの方法で処理する必要はありませんか?
  2. 対話ウィンドウをユーザーに送り返し、データ 2 APIの承認について同意します。エンド ユーザーにとって優れた UX にはなりません。
  3. どういうわけか、承認フロー全体を代理から変更しますか?

よくわかりません。助けていただければ幸いです。

4

2 に答える 2