Azure Active Directory でのアプリケーションの同意エクスペリエンス

この記事では、Azure Active Directory (Azure AD) アプリケーションの同意ユーザー エクスペリエンスについて学習します。 その後、ご自分の組織でアプリケーションをインテリジェントに管理したり、よりシームレスな同意エクスペリエンスでアプリケーションを開発したりすることができます。

同意は、保護されたリソースにアプリケーションが代理でアクセスする認証を、ユーザーが許可するプロセスです。 管理者またはユーザーは、組織または個人のデータへのアクセスを許可するように同意を求められることがあります。

同意を許可する実際のユーザー エクスペリエンスは、ユーザーのテナント、ユーザーの機関でのスコープ (ロール)、クライアント アプリケーションによって要求されているアクセス許可の種類に設定されたポリシーによって異なります。 つまり、そのアプリケーション開発者とテナント管理者は、同意エクスペリエンスの一部を制御できます。 管理者は、テナントで同意エクスペリエンスを制御するために、テナント上でポリシーまたはアプリを柔軟に設定および無効化することができます。 アプリケーション開発者は、どのような種類のアクセス許可を要求するか、およびユーザーの同意フローまたは管理者の同意フローをユーザーにガイドするかどうかを決定できます。

  • ユーザーの同意フローは、現在のユーザーのみに対する同意を記録する目的で、アプリケーション開発者がユーザーを承認エンドポイントに直接アクセスさせます。
  • 管理者の同意フローは、テナント全体に対する同意を記録する目的で、アプリケーション開発者がユーザーを管理者の同意エンドポイントに直接アクセスさせます。 管理者の同意フローが適切に動作するようにするため、アプリケーション開発者はアプリケーション マニフェストで RequiredResourceAccess プロパティのアクセス許可をすべて一覧する必要があります。 詳細については、アプリケーション マニフェストに関するページを参照してください。

同意プロンプトは、代理でクライアント アプリケーションが保護されたリソースにアクセスすることを信頼するかどうかを判断するために必要な情報を、ユーザーが確実に所有できるように設計されています。 構成要素を理解すると、ユーザーが許可する同意によって豊かな情報に基づく意思決定を下せるようになり、これにより、開発者はより適切なユーザー エクスペリエンスをビルドすることができます。

次の図と表では、同意プロンプトの構成要素に関する情報を示しています。

同意プロンプトの構成要素

# コンポーネント 目的
1 ユーザー識別子 この識別子は、クライアント アプリケーションが代わりに、保護されたリソースにアクセスすることを要求していることを表します。
2 タイトル このタイトルは、ユーザーの同意フローまたは管理者の同意フローのいずれをユーザーが経由しているかに基づいて変更されます。 ユーザーの同意フローでは、タイトルは “要求されているアクセス許可” になります。一方、管理者の同意フローでは、タイトルには “組織として承認する” の行が追加されます。
3 アプリのロゴ このイメージは、ユーザーがアクセスしようとしているアプリがこのアプリであるかどうかの目印になります。 このイメージは、アプリケーション開発者によって提供され、このイメージの所有権は検証されていません。
4 アプリの名前 この値によって、ユーザーのデータへのアクセスを要求しているアプリケーションをユーザーに通知します。 この名前は開発者によって提供され、このアプリ名の所有権は検証されていないことに注意してください。
5 発行元の名前と検証 青い "検証済み" バッジは、アプリの発行元が Microsoft Partner Network アカウントを使用して ID を検証し、検証プロセスを完了したことを意味します。 アプリの発行元が検証済みの場合は、発行元の名前が表示されます。 アプリの発行元が確認されていない場合は、発行元名の代わりに [未確認] と表示されます。 詳細については、「発行元の検証」を参照してください。 発行元名を選択すると、発行元名、発行元ドメイン、作成日、認定の詳細、応答 URL など、使用可能なアプリ情報が表示されます。
6 Microsoft 365 認定 Microsoft 365 認定ロゴは、業界をリードする業界標準フレームワークから派生したコントロールに対してアプリが検証されていること、および顧客データを保護するための強力なセキュリティとコンプライアンス プラクティスが実施されていることを意味します。 詳細については、Microsoft 365 認定に関する記事を参照してください。
7 パブリッシャー情報 アプリケーションが Microsoft によって公開されているかどうかが表示されます。
8 アクセス許可 この一覧には、クライアント アプリケーションによって要求されているアクセス許可が含まれます。 ユーザーは常に、同意する場合、クライアント アプリケーションが代理でアクセスすることが承認されるデータの内容を理解するために、要求されているアクセス許可の種類を評価する必要があります。 アプリケーション開発者は、最低限の特権を含むアクセス許可を要求することをお勧めします。
9 アクセス許可の説明 この値は、アクセス許可を公開しているサービスによって提供されます。 アクセス許可の説明を表示するには、アクセス許可の横にあるシェブロンを切り替える必要があります。
10 https://myapps.microsoft.com これは、現在、データへのアクセス権がある任意の Microsoft 以外のアプリケーションをユーザーが確認および削除できるリンクです。
11 こちらでご報告ください このリンクは、アプリを信頼できない場合、このアプリが他のアプリを偽装していると思われる場合、アプリがデータを誤用すると思われる場合、またはその他の理由で、疑わしいアプリを報告するために使用されます。

次のセクションでは、一般的なシナリオと、それぞれの想定される同意エクスペリエンスについて説明します。

アプリにはユーザーに付与する権限があるアクセス許可が必要である

この同意シナリオでは、ユーザーは、そのユーザーの権限の範囲内にあるアクセス許可セットを必要とするアプリにアクセスします。 ユーザーは、ユーザーの同意フローにリダイレクトされます。

管理者には、テナント全体の代わりに同意することを許可する、従来の同意プロンプトに追加のコントロールが表示されます。 コントロールは既定ではオフにされているため、管理者が明示的にチェック ボックスをオンにした場合にのみ、テナント全体の代わりに同意が許可されます。 このチェック ボックスは全体管理者ロールにのみ表示されるため、クラウド管理者とアプリ管理者にはこのチェック ボックスは表示されません。

シナリオ 1a の同意プロンプト

ユーザーには従来の同意プロンプトが表示されます。

従来の同意プロンプトを示しているスクリーンショット。

アプリにはユーザーに付与する権限がないアクセス許可が必要である

この同意シナリオでは、ユーザーは、ユーザーの権限の範囲外にある少なくとも 1 つのアクセス許可を必要とするアプリにアクセスします。

管理者には、テナント全体の代わりに同意することを許可する、従来の同意プロンプトに追加のコントロールが表示されます。

シナリオ 1a の同意プロンプト

管理者以外のユーザーは、アプリケーションへの同意の許可がブロックされ、そのアプリへのアクセス許可を管理者に要求するように指示されます。 ユーザーのテナントで管理者の同意ワークフローが有効になっている場合、管理者以外ユーザーは同意プロンプトから管理者の承認要求を送信できます。 管理者の同意ワークフローについて詳しくは、「管理者の同意ワークフロー」を参照してください。

アプリへのアクセスを管理者に依頼するようユーザーに通知する同意プロンプトのスクリーンショット。

この同意シナリオでは、ユーザーは管理者の同意フローに移動するか、リダイレクトされます。

管理ユーザーには管理者の同意プロンプトが表示されます。 タイトルとアクセス許可の説明はこのプロンプトで変更され、この変更によって許可するファクトが強調表示され、このプロンプトによってテナント全体の代わりに要求されたデータへのアクセス権がアプリに付与されます。

シナリオ 3a の同意プロンプト

管理者以外のユーザーは、アプリケーションへの同意の許可がブロックされ、そのアプリへのアクセス許可を管理者に要求するように指示されます。

アプリへのアクセスを管理者に依頼するようユーザーに通知する同意プロンプトのスクリーンショット。

このシナリオでは、管理者はアプリケーションによって要求されるすべてのアクセス許可に同意します。これには、テナント内のすべてのユーザーに代わって委任されたアクセス許可を含めることができます。 管理者は、Azure portal のアプリケーション登録の [API アクセス許可] ページを通じて同意を付与します。

Azure portal を使用した明示的な管理者の同意のスクリーンショット。

アプリケーションに新しいアクセス許可が必要でない限り、そのテナント内のすべてのユーザーには同意ダイアログが表示されません。 委任されたアクセス許可に同意できる管理者ロールについては、「Azure AD での管理者ロールのアクセス許可」を参照してください。

重要

現時点では、MSAL.js を使用するシングルページ アプリケーション (SPA) では、[アクセス許可の付与] ボタンを使用して明示的に同意を付与する必要があります。 そうしないと、アクセス トークンが要求されたときにアプリケーションでエラーが発生します。

一般的な問題

このセクションでは、同意エクスペリエンスに関する一般的な問題と考えられるトラブルシューティングのヒントについて説明します。

  • 403 エラー

    • これは委任シナリオですか? ユーザーはどのようなアクセス許可を持っていますか?
    • エンドポイントを使用するために必要なアクセス許可が追加されていますか?
    • トークンを確認して、エンドポイントを呼び出すために必要な要求があるかどうかを確かめます。
    • 同意されたのは、何のアクセス許可ですか? だれが同意したのですか?
  • ユーザーが同意できない

    • テナント管理者が組織のユーザーの同意を無効にしているかどうかを確認します
    • 要求するアクセス許可が、管理者によって制限されているアクセス許可であるかどうかを確認します。
  • 管理者が同意した後もユーザーがブロックされる

    • 静的アクセス許可が、動的に要求されたアクセス許可のスーパーセットとして構成されているかどうかを確認します。
    • アプリにユーザー割り当てが必要かどうかを確認します。

既知のエラーのトラブルシューティングを行う

トラブルシューティング手順については、「アプリケーションに同意すると、予期しないエラーが発生する」を参照してください。

次のステップ