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

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

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

ユーザーの同意エクスペリエンス

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

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

管理者の同意のエクスペリエンス

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

ただし、Microsoft Entra 管理センターの [ユーザーの同意設定] の次のスクリーンショットの例に示されているとおり、テナント管理者は、[ユーザーの同意を許可しない] (すべてのアクセス許可で管理者の同意が必要) でテナントを構成できるため、どのアクセス許可で管理者の同意が必要になり、どのアクセス許可で一般ユーザーの同意が許可されるかはわかりません。

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

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

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

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

アクセス許可と同意エクスペリエンスの向上

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

[管理者の同意要求] では、テナント管理者は、「ユーザーは、自分が同意できないアプリに対して管理者の同意を要求できます」で [はい] を選択し、その他の [管理者の同意要求] 設定を構成することで、ユーザーのアクセス許可と同意エクスペリエンスを向上できます。

テナント管理者が「ユーザーは、自分が同意できないアプリに対して管理者の同意を要求できます」で [はい] を選択した後、アプリケーションで管理者の同意を必要とするアクセス許可を要求すると、ユーザーには次のような [承認が必要] ダイアログが表示され、より良いユーザー エクスペリエンスが提供されます。

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

管理者が Microsoft Entra 管理センターで同意を構成せずに、管理者の同意が必要なアプリケーションを実行すると、管理者ユーザーには次の例のような [アクセス許可が必要] ダイアログが表示されます。

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

テナント管理者の同意のもう 1 つの方法は、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 の基本を学ぶのに役立ちます。