管理者の同意を必要とするアクセス許可の要求

この記事では、開発者として、管理者の同意を必要とするアプリケーションのアクセス許可を要求するアプリケーション コードを記述するシナリオでの、アクセス許可と同意エクスペリエンスについて説明します。 アクセス許可と同意のダイアログのスクリーンショットの例と Microsoft Entra 管理センターでは、ユーザーとテナント管理者のエクスペリエンスがわかります。 管理者との共同作業を向上させ、アプリケーションで最小権限のゼロ トラスト原則を実装してください。

アプリケーションを開発するときには、特定のスコープ (またはアクセス許可) を持つアクセス トークンを要求することで、リソースへのアクセスを要求するコードを記述します。 一部のユーザーがアクセス許可として記述する OAuth 2.0 標準の説明に従って、スコープ パラメーターを使用します。 リソース所有者は、アクセス許可を求める各要求を許可または拒否します。 Microsoft Entra ID では、リソース所有者はアプリのユーザーか、すべてのユーザーに代わってそのリソースに同意する権限を持つ管理者です。

アプリケーションがリソースへのアクセス許可を要求すると、次の例のような [アクセス許可が要求されました] ダイアログがユーザーに表示される場合があります。

[キャンセル] ボタンと [承諾] ボタンがある、アプリが要求しているアクセス許可を説明する [要求されているアクセス許可] ダイアログのスクリーンショット。

上の例のダイアログでは、ユーザーは [Accept] (承諾) を選択してアプリが自分の代わりにデータを読み取ることを許可する同意を付与するか、[Cancel] (キャンセル) を選択してその要求を拒否します。 アプリケーションはアクセス トークンを受け取り、ユーザーが同意を付与した後もプロセスを続行できます。 トークンを受け取らないとアプリは適切に処理できないことを忘れないでください。

一部のアクセス要求では、管理者のみが同意を付与できます。 要求されたアクセスが強力であるか、所有者が現在のユーザーではないリソースを含む場合は、管理者のみが要求を許可できるようにコードを記述します。

ただし、次の例で Microsoft Entra 管理センター[User consent settings] (ユーザー同意設定) のスクリーンショットに示すように、テナント管理者は [Do not allow user consent] (ユーザーの同意を許可しない) (すべてのアクセス許可は管理者の同意を必要とする) でテナントを構成できるため、管理者の同意が必要なアクセス許可と、通常のユーザーが同意を許可する権限を知ることはありません。

アプリケーションが組織のデータにアクセスするための同意を構成する Microsoft Entra 管理センターの [ユーザーの同意設定] のスクリーンショット。

管理者は、Microsoft Entra 管理センターの次の [ユーザーの同意設定] の例のスクリーンショットに示すように、選択したアクセス許可に対して、検証済みの発行元からのアプリに対するユーザーの同意を許可することもできます。

検証済みの発行元からのアプリの同意を構成する Microsoft Entra 管理センターの [ユーザーの同意設定] のスクリーンショット。

次の例で Microsoft Entra 管理センターの [Permission classifications] (アクセス許可の分類) のスクリーンショットに示すように、管理者はユーザーが同意できるアクセス許可を追加できます。

ユーザーの同意を許可するアクセス許可の分類を構成する Microsoft Entra 管理センターの [アクセス許可の分類] のスクリーンショット。

アプリが管理者の同意を必要とするアクセス許可を (設計または管理者の構成によって) 要求すると、次の例のような [Need admin approval] (管理者の承認が必要です) ダイアログが表示される場合があります。

要求されたアクセス許可は管理者のみが付与できる方法を説明する [管理者の承認が必要] ダイアログのスクリーンショット。

上の例のダイアログは、管理者の同意を必要とするアクセス許可の既定 (追加設定なし) のエクスペリエンスを示しています。 ほとんどのユーザーは、このシナリオで何をすべきかわかっていません。 管理者が誰であるかはわからず、承認のために誰にアクセスすればいいかわかりません。 この不明瞭さにより、ユーザーが望ましい結果を得る能力が制限されている可能性があります。

アクセス許可と同意エクスペリエンスを向上させるために、テナント管理者は、次の例で Microsoft Entra 管理センターの [User settings] (ユーザー設定) のスクリーンショットに示すように、管理者の同意ワークフローを構成できます。

[管理者の同意要求] を構成する Microsoft Entra 管理センターの [ユーザー設定] のスクリーンショット。

[Admin consent requests] (管理者の同意の要求) の下では、テナント管理者は、[Users can request admin consent to apps they're unable to consent to] (ユーザーは同意できないアプリに対して管理者の同意を要求できる) で [Yes] (はい) を選択し、他の [Admin consent requests] (管理者の同意の要求) 設定を構成することで、ユーザーのアクセス許可と同意エクスペリエンスを向上させることができます。

テナント管理者が [Users can request admin consent to apps they're unable to consent to] (ユーザーは同意できないアプリに対して管理者の同意を要求できる) で [Yes] (はい) を選択し、アプリケーションが管理者の同意を必要とするアクセス許可を要求すると、ユーザー エクスペリエンスを向上させる次の [Approval required] (承認が必要です) ダイアログのようなものが表示されます。

[このアプリを要求する正当な理由を入力してください] という入力のためのテキスト フィールドでアプリが要求しているアクセス許可を説明する [承認が必要] ダイアログのスクリーンショット。

上の例のダイアログでは、[Request approval] (承認の要求) を選択する前に、このアプリを要求するための正当な理由を入力できます。 そして承認の要求により、管理者がリスク プロファイルに基づいて組織内のアプリケーションを確認、承諾、または禁止することを選択できる [Admin consent requests] (管理者の同意の要求) キュー (下のスクリーンショット例) に入力されます。

保留中の要求を構成する Microsoft Entra 管理センター [管理者の同意要求] のスクリーンショット。

管理者が管理者の同意を必要とするアプリケーションを実行する場合 (そして管理者が Microsoft Entra 管理センターでその同意をまだ構成していない場合)、管理者ユーザーには、次の例のように少し異なる [Permissions requested] (アクセス許可が要求されました) ダイアログが表示されます。

アプリが要求しているアクセス許可を説明する、[組織の代理として同意する] を切り替えるチェック ボックスがある [要求されているアクセス許可] ダイアログのスクリーンショット。

上の例では、管理者には、アプリケーションが要求しているアクセス許可の説明が表示されます。 管理者は [Accept] (承諾) を選択してアプリケーションを個別に実行するか、[Consent on behalf of your organization] (組織に代わって同意) を選択してから [Accept] (承諾) を選択することができます。 管理者が組織に対する同意を付与すると、管理者がテナントの [Admin consent requests] (管理者の同意の要求) 設定から同意を削除しない限り、その後の組織ユーザーはこのアプリケーションに対してアクセス許可を付与する必要はありません。

テナントの管理者の同意のもう 1 つの方法は、この例のようにアプリが既に要求している既存のアクセス許可の詳細を管理者が確認できる、Microsoft Entra 管理センターの [Permissions] (アクセス許可) です。

既存のアプリケーション要求の詳細を表示する Microsoft Entra 管理センターの [アクセス許可] のスクリーンショット。

上の [User consent] (ユーザーの同意) の例では、管理者は、要求、アクセス許可のタイプ、および同意したユーザーに関する情報と共に、アプリに対して付与されたアクセス許可を確認できます。 管理者は、[Admin consent] (管理者の同意) を選択して、管理者の同意を必要とする付与されたアクセス許可を確認できます。

最適なアプリケーションのアクセス許可の戦略は、アプリを登録するときに アプリが必要とするか、最終的に要求するすことになる、すべてのアクセス許可を事前に宣言することです。 すべてのアクセス許可を同時に要求する必要はありませんが、アプリに必要なすべてのアクセス許可を宣言した後は、管理者はテナント内のアプリの構成で [Grant admin consent for] (管理者の同意の付与対象) を選択して、次の例のようなダイアログを表示できます。

[キャンセル] ボタンと [承諾] ボタンがある、アプリが要求しているアクセス許可を説明する、組織が確認するための [要求されているアクセス許可] ダイアログのスクリーンショット。

上の例は、管理者が宣言したアクセス許可に事前に同意し、ユーザーとテナント管理者に最適なエクスペリエンスを提供する方法を示しています。

事前に管理者の同意を要求することは、基幹業務 (LOB) アプリ、特に組織が開発しているアプリに最適な選択です。 これらのアプリケーションに事前に同意することで、会社が会社のデータにアクセスできるかどうかをユーザーに尋ねる必要がないようにする方が簡単です。 アプリ登録プロセスの一環として、ユーザーは管理者の同意の要求を行います。

次のステップ

  • リソースにアクセスするための承認を取得すると、アプリケーションのリソース アクセス許可を取得するときにゼロ トラストを確実に行う方法を理解するのに役立ちます。
  • API 保護では、登録を通じて API を保護し、アクセス許可と同意を定義し、ゼロ トラストの目標を達成するためのアクセスを強制するためのベスト プラクティスについて説明します。
  • 承認のベスト プラクティスは、アプリケーションに最適な承認、アクセス許可、および同意モデルを実装するのに役立ちます。
  • トークンのカスタマイズでは、Microsoft Entra トークンで受信することができる情報と、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるためにトークンをカスタマイズする方法について説明します。
  • Microsoft ID プラットフォームでのアクセス許可と同意の概要」は、アクセスと認証の基本的な概念を理解するのに役立ちます。
  • 同意とアクセス許可の概要は、Microsoft Entra ID での同意とアクセス許可に関する基本的な概念とシナリオを学習するのに役立ちます。
  • Learn モジュール:「Permissions and consent framework」は、アクセス許可と同意のフレームワーク モデルを学習するのに役立ちます。
  • Learn ライブ:「Microsoft Identity: Permissions and Consent Framework」は、トークン、アカウント タイプ、トポロジなど、Microsoft ID の基本を学ぶのに役立ちます。