Microsoft Entra ID でのアプリケーションの同意エクスペリエンス
この記事では、Microsoft Entra アプリケーションの同意ユーザー エクスペリエンスについて説明します。 これにより、ご自分の組織でアプリケーションをインテリジェントに管理したり、よりシームレスな同意エクスペリエンスでアプリケーションを開発したりすることができます。
同意は、保護されたリソースにアプリケーションが代理でアクセスする認証を、ユーザーが許可するプロセスです。 管理者またはユーザーは、組織または個人のデータへのアクセスを許可するように同意を求められることがあります。
同意を許可する実際のユーザー エクスペリエンスは、ユーザーのテナント、ユーザーの機関でのスコープ (またはロール)、クライアント アプリケーションによって要求されているアクセス許可の種類に設定されたポリシーによって異なります。 つまり、そのアプリケーション開発者とテナント管理者は、同意エクスペリエンスの一部を制御できます。 管理者は、テナントで同意エクスペリエンスを制御するために、テナント上でポリシーまたはアプリを柔軟に設定および無効化することができます。 アプリケーション開発者は、どのような種類のアクセス許可を要求するか、およびユーザーの同意フローまたは管理者の同意フローをユーザーにガイドするかどうかを決定できます。
- ユーザーの同意フローは、現在のユーザーのみに対する同意を記録する目的で、アプリケーション開発者がユーザーを承認エンドポイントに直接アクセスさせます。
- 管理者の同意フローは、テナント全体に対する同意を記録する目的で、アプリケーション開発者がユーザーを管理者の同意エンドポイントに直接アクセスさせます。 管理者の同意フローが適切に動作するようにするため、アプリケーション開発者はアプリケーション マニフェストで
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 | こちらでご報告ください | このリンクは、アプリを信頼できない場合、このアプリが他のアプリを偽装していると思われる場合、アプリがデータを誤用すると思われる場合、またはその他の理由で、疑わしいアプリを報告するために使用されます。 |
一般的なシナリオと同意エクスペリエンス
次のセクションでは、一般的なシナリオと、それぞれの想定される同意エクスペリエンスについて説明します。
アプリにはユーザーに付与する権限があるアクセス許可が必要である
この同意シナリオでは、ユーザーは、そのユーザーの権限の範囲内にあるアクセス許可セットを必要とするアプリにアクセスします。 ユーザーは、ユーザーの同意フローにリダイレクトされます。
管理者には、テナント全体を代表して同意を与えることができる従来の同意プロンプトに別のコントロールが表示されます。 コントロールは既定ではオフにされているため、管理者が明示的にチェック ボックスをオンにした場合にのみ、テナント全体の代わりに同意が許可されます。 このチェックボックスが表示される対象は、特権ロール管理者ロール以上であるため、クラウド管理者とアプリ管理者にはこのチェックボックスは表示されません。
ユーザーには従来の同意プロンプトが表示されます。
アプリにはユーザーに付与する権限がないアクセス許可が必要である
この同意シナリオでは、ユーザーは、ユーザーの権限の範囲外にある少なくとも 1 つのアクセス許可を必要とするアプリにアクセスします。
管理者には、テナント全体の代わりに同意することを許可する、従来の同意プロンプトに追加のコントロールが表示されます。
管理者ではないユーザーはアプリケーションへの同意をブロックされ、管理者にアプリへのアクセスを求めるように指示されます。 ユーザーのテナントで管理者の同意ワークフローが有効になっている場合、ユーザーは同意プロンプトから管理者の承認を求めるリクエストを送信できます。 管理者の同意ワークフローについて詳しくは、「管理者の同意ワークフロー」を参照してください。
ユーザーが管理者の同意フローにリダイレクトされる
この同意シナリオでは、ユーザーは管理者の同意フローに移動するか、リダイレクトされます。
管理ユーザーには管理者の同意プロンプトが表示されます。 タイトルとアクセス許可の説明はこのプロンプトで変更され、この変更によって許可するファクトが強調表示され、このプロンプトによってテナント全体の代わりに要求されたデータへのアクセス権がアプリに付与されます。
ユーザーはアプリケーションへの同意の許可からブロックされ、そのアプリへのアクセス許可を管理者に要求するように指示されます。
Microsoft Entra 管理センターを使用した管理者の同意
このシナリオでは、管理者はアプリケーションによって要求されるすべてのアクセス許可に同意します。これには、テナント内のすべてのユーザーに代わって委任されたアクセス許可を含めることができます。 管理者は、Microsoft Entra 管理センターのアプリケーション登録の [API のアクセス許可] ページで同意を許可します。
アプリケーションに新しいアクセス許可が必要でない限り、そのテナント内のすべてのユーザーには同意ダイアログが表示されません。 委任されたアクセス許可に同意できる管理者ロールについては、「Microsoft Entra ID の管理者ロールのアクセス許可」を参照してください。
重要
現時点では、MSAL.js を使用するシングルページ アプリケーション (SPA) では、[アクセス許可の付与] ボタンを使用して明示的に同意を付与する必要があります。 そうしないと、アクセス トークンが要求されたときにアプリケーションでエラーが発生します。
一般的な問題
このセクションでは、同意エクスペリエンスに関する一般的な問題と考えられるトラブルシューティングのヒントについて説明します。
403 エラー
ユーザーが同意できない
- テナント管理者が組織のユーザーの同意を無効にしているかどうかを確認します
- 要求するアクセス許可が、管理者によって制限されているアクセス許可であるかどうかを確認します。
管理者が同意した後もユーザーがブロックされる
- 静的アクセス許可が、動的に要求されたアクセス許可のスーパーセットとして構成されているかどうかを確認します。
- アプリにユーザー割り当てが必要かどうかを確認します。
既知のエラーのトラブルシューティングを行う
トラブルシューティング手順については、「アプリケーションに同意すると、予期しないエラーが発生する」を参照してください。
関連項目
- Microsoft Entra の同意フレームワークの実装方法の詳細な手順を入手します。
- 詳細については、マルチテナント アプリケーションが同意フレームワークを使用して多層アプリケーションのパターンのサポートが強化されている、"user" と "admin" の同意を実装する方法について説明します。
- アプリの発行元ドメインを構成する方法について説明します。