Microsoft Entra ID を使用してアプリケーション、リソース、ワークロードを承認する

  • [アーティクル]

この記事では、アプリケーション プログラミング インターフェイス (API) がユーザーの役割を果たす場合に、個々の人間がアプリケーションを操作して、指示するときの承認について説明します。 また、アプリケーションまたはサービスが単独で動作する場合についても説明します。 これは、独立系ソフトウェア開発者 (ISV) が Microsoft Entra ID 用にアプリケーションを構築および最適化する方法に関する一連の記事の 4 番目です。 このシリーズでは、次のトピックの詳細を確認できます。

アプリケーションでの承認

このセクションでは、個々の人間がアプリケーションを操作して指示するシナリオについて説明します。 「リソース (API) での承認」セクションでは、ユーザーがリソースにアクセスするための承認は必要であるが、Microsoft Entra ID は最終的な承認を行わない場合に、API が承認を実行する方法について説明します。 「ワークロードでの承認」セクションでは、アプリケーションまたはサービスが単独で動作するシナリオについて説明します。

アプリケーションは、ユーザーに代わってリソースにアクセスする必要がある場合に、次の承認を必要とします。

  • アプリケーションには、現在のユーザーのために特定のリソース内の特定の操作にアクセスするための承認が必要です。
  • ユーザーは、現在の条件下でリソースにアクセスするための承認を得ている必要があります。
  • ユーザーは、リソースにアクセスするための承認を得ている必要があります。

承認プロセスは、OAuth 2.0 を使用するアプリケーションが、Microsoft Entra ID からアクセス トークンを要求し、ユーザーの特定のリソース内の特定の操作にアクセスすることから始まります。 委任されたアクセスでは、アプリはユーザーの代理人として機能します。

開発者は、リソースには、Microsoft Graph、Azure Storage、または独自の API などの API を使用できます。 ただし、ほとんどの API には、読み取りと書き込みなどのさまざまな操作があります。 アプリケーションが API からの読み取りのみを行う場合、アプリは読み取り操作の身を承認する必要があります。 この方法は、侵害され、開発者が意図したよりも多くのアクセスに使用されることからアプリケーションを保護します。 アプリケーションを必要な操作に対してのみ承認する場合、開発者は最小限の特権の原則に従っています。

アプリケーションが必要とする、特定の API における特定の操作を指定するために、開発者は OAuth 2.0 要求のスコープ パラメーターを使用します。 API デザイナーは、アプリケーションが API のアプリ登録の一部として要求できるスコープを発行します。 たとえば、Microsoft Power BI サービスのスコープには、次のようなものがあります。

Power BI サービスのスコープ 操作
https://analysis.windows.net/powerbi/api/Capacity.Read.All アプリは、サインインしているユーザーがアクセスできるすべての Power BI Premium および Power BI Embedded 容量を表示できます。
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All アプリは、サインインしているユーザーがアクセスできるすべての Power BI Premium および Power BI Embedded 容量を表示および編集できます。

アプリケーションが容量の読み取りのみを行う場合、アプリはスコープを https://analysis.windows.net/powerbi/api/Capacity.Read.All 要求します。 アプリケーションが容量を編集する場合には、アプリはスコープを https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All 要求します。

スコープには、API の ID と操作の ID が含まれます。 https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All スコープでは、API は https://analysis.windows.net/powerbi/api です。 操作は Capacity.ReadWrite.All です。 Microsoft Graph API は幅広い利用者と支持を得ていることから、開発者は Microsoft Graph のスコープについてはスコープの API コンポーネントなしで要求できます。 たとえば、Microsoft Graph では、https://graph.microsoft.com/Files.Read というスコープが定義されており、アプリケーションは完全なスコープ名を使用する代わりに Files.Read で要求できます。

初回の承認を完了するには、アプリケーションは、現在のユーザーが特定のリソース内の特定の操作にアクセスするための承認を持っている必要があります。Microsoft Entra ID は、最初に現在のユーザーを認証する必要があります。 シングル サインオン (SSO) は、この認証を満たすことができます。または、新たなユーザー操作が必要な場合があります。

Microsoft Entra ID は、ユーザーを特定した後、要求されたスコープに対してユーザーがアプリケーションを承認したかどうかを確認します。 このプロセスは、同意の付与と呼ばれます。 ユーザーが同意を与えた場合、承認プロセスは続行できます。 管理者の同意では、管理者ユーザーは自分自身と組織全体に対して同意できます。 Microsoft Entra ID は、アプリケーションがスコープに対して管理者の同意を持っているかどうかを確認します。 同意が与えられている場合、承認プロセスは続行されます。

スコープの設計時に、API デザイナーは、管理者のみが同意できるスコープを指定できます。 管理者の同意を必要とするスコープは、より機密性の高い、強力、または広範に影響を与えるものであるため、管理者以外のユーザーがアプリケーションに付与する権限を持つべきではないと API デザイナーが見なした操作を表します。

どのスコープが管理者の同意を必要とするかを最初に決めるのは API デザイナーですが、これは最終的なものではありません。 API デザイナーがあるスコープを管理者の同意が必要と指定した場合、そのスコープには常に管理者の同意が必要です。 API デザイナーが管理者の同意を必要としないと指定したスコープに対しては、テナント管理者は管理者の同意を要求できます。また、リスクベースのステップアップ同意によって管理者の同意要件が決まる場合もあります。 開発者は、トークン要求に管理者の同意が必要かどうかを予測することはできません。 ただし、この制限は、必要とされるコードには影響しません。 同意拒否は、トークン要求拒否の多くの理由の 1 つに過ぎません。 アプリケーションは常に、トークンの非受信を適切に処理する必要があります。

ユーザーまたは管理者が同意を付与していない場合は、次の例に示すようは同意プロンプトが表示されます。

ユーザーの同意プロンプトのスクリーンショット。

管理者ユーザーの同意プロンプトでは、次の例に示すように、組織に代わって同意を選択して、テナント内のすべてのユーザーに同意を付与することができます。

管理者の同意プロンプトのスクリーンショット。

アプリケーションは、ユーザーの同意プロンプトのタイミングを制御します。 Microsoft Entra ID は静的同意をサポートしています。アプリケーションが .default スコープを使用すると、アプリはアプリの登録で宣言されたすべてのアクセス許可を要求します。 静的同意では、アプリは必要とする可能性のあるすべてのアクセス許可を事前に要求します。

静的同意は、ユーザーと管理者がアプリのアクセス要求を承認するのを防げる可能性があります。 同意要求プロセスのベスト プラクティスは、アプリケーションの起動時にアプリケーションのベースライン機能に必要なアクセス許可を動的に要求し、必要な時に都度さらにスコープを要求することです。 アプリケーションが、より多くのスコープを必要とする操作を実行するに従って、その分のスコープを増分要求します。 この方法では、機能のタイミングと関連する他のアクセス許可についてより深く理解できます。 各 API アクセス トークンについては、Microsoft Entra ID では、要求内のスコープだけでなく、以前にアプリケーションに付与されたすべてのスコープが含まれます。

たとえば、アプリケーションは、アプリケーションの起動時にユーザーのサインインとユーザーのプロファイルへのアクセスのために https://graph.microsoft.com/user.read を要求できます。 その後、ユーザーが [OneDrive に保存] を選択すると、アプリケーションはユーザーの OneDrive にファイルを書き込むために https://graph.microsoft.com/files.readwrite を要求します。 アプリが OneDrive への書き込みを求めている理由がユーザーに表示されるため、ユーザーはアクセス許可を付与し、アプリはユーザーの OneDrive にファイルを保存します。 その後、ユーザーはアプリを閉じます。 次にアプリを起動すると、アプリは https://graph.microsoft.com/user.read を要求します。 Microsoft Entra ID は、https://graph.microsoft.com/user.read スコープと https://graph.microsoft.com/files.readwrite スコープを持つアクセス トークンを返します。 https://graph.microsoft.com/files.readwrite スコープに対するトークン要求は、ユーザーから許可されているため同意の必要はありません。 Microsoft Authentication Libraries (MSAL) のトークン キャッシュは、付与されたアクセス許可に基づいてキャッシュ トークンを自動的に処理します。 この例では、アプリの再起動後、https://graph.microsoft.com/files.readwrite スコープを持つトークンを取得するための MSAL への呼び出しに対し、https://graph.microsoft.com/user.read スコープに対するアプリの最初の要求でキャッシュされたトークンが返されます。 Microsoft Entra ID に対する再度の呼び出しは不要です。

動的な増分同意では、アプリケーションの登録中に宣言されたアクセス許可は必要ありません。 ただし、静的同意をサポートするためにアプリケーションの登録に必要なアクセス許可を宣言しておくことを強くお勧めします。 管理者は、Microsoft Entra 管理センター、Microsoft Graph PowerShell 、または Microsoft Graph API を使用して、管理者の同意を付与できます。

アプリケーションの管理者の同意を付与するために、Microsoft Entra 管理センターは、静的同意を使用してアプリの .default スコープについて同意を要求します。 開発者がアプリ登録で管理者の同意を宣言してない場合、管理者は、アクセス許可を必要とするアプリに Microsoft Entra 管理センターで管理者の同意を付与することはできません。

Microsoft Entra ID の顧客は、条件付きアクセス ポリシーを使用して、リソース (API) とブラウザー ベースのアプリケーションを保護できます。 既定では、管理者はネイティブ アプリ認証には条件付きアクセス ポリシーを適用できません。 テナント管理者は、すべてのクラウド アプリを対象にするか、カスタム セキュリティ属性を使用して条件付きアクセス ポリシーを持つネイティブ アプリを対象にすることができます。 対象がそれ以外の場合でも、ポリシーの適用には、Microsoft Graph または Azure AD Graph にアクセスする一部のアプリは含まれません。

通常、アプリケーションでは、次のシナリオが適用される場合を除き、条件付きアクセスに特別なコードは必要ありません。

  • On-Behalf-Of フローを実行するアプリ
  • 複数のサービスまたはリソースにアクセスするアプリ
  • MSAL.js を使用するシングルページ アプリ
  • リソースを呼び出す Web アプリ

アプリでこれらのシナリオのいずれかが実装されている場合は、「Microsoft Entra 条件付きアクセスの開発者向けガイダンス」を確認してください。

無料の Microsoft Entra ID テナントは条件付きアクセスを利用できません (ライセンス要件を参照してください。 会社の運用テナントが必要なライセンスを持っている場合があります。 運用テナントを使用してテストする前に、これらの条件を評価します。 テスト テナントを作成するためのガイダンスもあります。

既定では、アプリ レベルでアプリがアクセスするアプリケーションとリソースに対して条件付きアクセス ポリシーが適用されます。 IT 管理者は、開発者の参加なしでも、アプリ レベルのポリシーを任意のアプリに適用できます。 一部のアプリケーションやシナリオでは、より細かい粒度が必要です。 たとえば、財務アプリでは、一般的な用途で多要素認証が必要な場合があります。 ただし、指定された金額を超えるトランザクションには、マネージド デバイスが必要な場合があります。 開発者は、条件付きアクセス認証コンテキストを実装することで、IT 管理者がアプリケーションのさまざまな領域にステップアップ条件付きアクセス ポリシーを割り当てられるようにできます。 「条件付きアクセス認証コンテキスト に関する開発者ガイド」は、これらの機能に関する適切なリファレンスです。

既定では、Microsoft Entra ID は、設定された時刻に有効なアクセス トークンを発行します。 アプリケーションでは、有効期間の長さについて何も想定しないでください。 Microsoft Entra ID がアクセス トークンと共に返す expires_in パラメーターを使用する必要があります。 MSAL はこのシナリオを自動的に処理します。 アクセス トークンの有効期間中、ユーザーは承認時の条件下でリソースにアクセスすることが許可されます。

条件が変更されてからポリシー変更の適用が行われるまでの遅延には、管理者とユーザーの懸念となる場合があります。 たとえば、ユーザーがデバイスを紛失した場合、IT 管理者はユーザーのセッションを取り消すことができます。 ただし、紛失したデバイス上のアプリは、トークンの有効期限が切れるまで、ユーザーの Microsoft Graph に引き続きアクセスできます。 Microsoft の継続的アクセス評価 (CAE) は、CAE を採用するアプリケーションでのユーザー セッション失効後のアクセスを防ぐことができます。 アプリケーションが少なくとも 1 時間に 1 回 Microsoft Graph を呼び出す場合、CAE を採用できます。 実装の詳細については「継続的アクセス評価が有効な API をアプリケーションで使用する方法」を参照してください。

MSAL でビルドできない場合は、アプリでは OAuth 2.0 を使用して Microsoft Entra ID からアクセス トークンを要求する必要があります。 Microsoft ID プラットフォームと OAuth 2.0 承認コード フローでは、Microsoft Entra ID がサポートするフローの実装の詳細が提供されます。

モバイル デバイス アプリを構築する場合は、「モバイル アプリでの SSO とアプリ保護ポリシーをサポートする」を参照してください。 トークンの取得、Intune モバイル アプリケーション管理 (MAM)、アプリ保護ポリシーをサポートする方法について説明します。

リソース (API) での承認

「アプリケーションでの承認」セクションでは、アプリケーションがユーザーのためにリソースにアクセスする場合に必要 3 つの承認を紹介しましたが、カバーしたのは最初の 2 つのみでした。 ユーザーはリソースにアクセスするための承認を持っている必要がありますが、Microsoft Entra ID は最終的な承認を実行しません。 承認はリソース (API) が実行します。

API は、ユーザーとして動作するときには、次の 2 つの承認を適用する必要があります。

  • API は、アプリが API を呼び出すことを承認する必要があります。 アクセス トークンの scp (スコープ) 要求に必要なスコープが含まれていることを確認します。
  • API は、ユーザーが特定のリソースにアクセスすることを承認する必要があります。 トークン内の oid (オブジェクト ID) 要求と sub (サブジェクト) 要求は、ユーザー ID を表します。

承認には oid 要求と sub 要求をお勧めします。

Microsoft Entra ID はペアワイズ sub 要求を実装するため、sub 要求は要求元アプリについての一意のユーザー識別子です。 別のアプリを使用している同じユーザーは、異なる sub 要求を持っています。 oid 要求は、すべてのアプリのユーザーについて一定です。

アプリケーションは、API に必要なアクセス トークンを提供します。それを Microsoft Entra ID は http 要求承認ヘッダーでベアラー トークンとして保護します。 トークンが Microsoft Entra ID から直接取得されないため、API は受信したトークンを完全に検証する必要があります。 呼び出し元のアプリは、トークンが検証されるまでは信頼できないと考えてください。 「アクセス トークンリファレンス」と「要求検証リファレンス」の記事では、Microsoft Entra ID アクセス トークンの検証に関する詳細を提供します。

Microsoft Entra ID は、API がトークンの署名を検証するために使用する公開キーを発行します。 これらのキーは、定期的に、かつ、状況により公開キーのロールオーバーが必要な場合に、ロールオーバーされます。 アプリケーションでは、公開キーのロールオーバーのスケジュールについて何も想定しないでください。 「Microsoft ID プラットフォームでの署名キーのロールオーバー」では、公開キーのロールオーバーを適切に処理する方法について説明します。

適切に保守されたライブラリを使用してトークンの検証を実行することをお勧めします。 ASP.NET または ASP.NET Core で Web アプリまたは API を構築する場合は、トークンの検証を処理するために Microsoft.Identity.Web を使用します。 「保護された Web API」の使用方法に関する記事では、API を保護するために Microsoft.Identity.Web を使用する方法について説明します。

API は、他の API を呼び出す必要がある場合があります。 アプリがユーザーのために動作する場合、API は現在のユーザーの ID を含む委任されたアクセス トークンを受け取ります。 ここでは、API が、Microsoft Entra ID の検証済みトークンのみを信頼して、現在のユーザーの ID を判断することが重要です。 この方法により、アプリケーションが侵害されてユーザーが他のユーザーを偽装したり、別のユーザーのリソースにアクセスしたりするのを防ぐことができます。 ある API が別の API を呼び出すときに同じ保護を行うには、On-Behalf-Of OAuth フローを使用して、API が呼び出されたユーザーの API を呼び出すアクセス トークンを取得します。 API が現在のアプリ ユーザーに対して他の API を呼び出す手順については、「Web API を呼び出す Web API を構築する」を参照してください。

委任されたアクセスに加えて、API はアプリケーションをサポートし、現在のユーザーなしで独立して動作することが必要になる場合があります。 Microsoft Entra ID は、これらのアプリケーションをワークロードと見なします。 ワークロードの承認を適用するためには、API は scp (スコープ) 要求を使用しません。 代わりに、API は roles 要求を使用して、ワークロードに必要な同意があることを検証します。 API は、ワークロードがリソースにアクセスするための承認をかならず持っているようにする役割を担います。

ワークロードでの承認

ワークロードは、独立して動作し、現在のユーザーがいないアプリケーションです。 「アプリケーションでの承認」セクションで説明されている委任されたアクセスと同様に、アプリのみのアクセスには、いくつかの承認が必要です。

  • アプリケーションでは、特定のリソース内の特定の操作にアクセスするための承認が必要です。
  • アプリケーションには、現在の条件下でリソースにアクセスするための承認が必要です。
  • アプリケーションには、リソースにアクセスするための承認が必要です。

このプロセスは、.default スコープ (https://graph.microsoft.com/.default など) を持つアクセス トークンを要求するワークロードから始まります。 委任されたアクセス (アプリケーションは動的に増分スコープを要求できる) とは異なり、ワークロードでは常に静的同意と .default スコープを使用する必要があります。

API デザイナーは、API のアプリ登録 にロールを追加することで、API のアプリのアクセス許可を作成します。 これらのロールには、ワークロードへのロールの割り当てを許可する、許可されたメンバーの種類のアプリケーションがあります。 Microsoft Entra 管理センターまたは Microsoft Graph を使用して、ワークロードにロールを割り当てます。 Microsoft Entra 管理センターでは、ワークロードを実行する前に、割り当てられたロールに対する管理者の同意が必要です。

既定では、アプリのアクセス許可によって、ワークロードがリソースのすべてのインスタンスにアクセスすることが承認されます。 たとえば、https://graph.microsoft.com/user.read.all は、テナント内のすべてのユーザーの完全なユーザー プロファイルにアクセスするワークロードを承認します。 多くの場合、IT 管理者はこれらの広範なアクセス許可を付与することに消極的です。

Microsoft Graph にアクセスするワークロードの場合は、次の方法を使用してアプリケーションのアクセス許可を制限します。

ユーザーのいるアプリケーションとは異なり、ワークロードは Microsoft Entra ID に対して自身を認証します。

Microsoft Azure で実行されるワークロードの場合、ワークロード自体を認証するための最適な方法は、Azure リソースのマネージド ID です。 マネージド ID 機能により、ワークロードの資格情報を管理する必要がなくなります。 アクセス可能な資格情報はありません。 Microsoft Entra ID が資格情報を完全に管理します。 管理する資格情報がないため、資格情報が侵害されるリスクはありません。

セキュリティが強化され、マネージド ID も回復性が向上します。 マネージド ID では、Microsoft Entra ID からの有効期間の長いアクセス トークンと情報を使用して、トークンの有効期限が切れる前に新しいトークンを取得します。 マネージド ID ではリージョン エンドポイントを使用します。これは、サービスの依存関係を統合することでリージョン外エラーを防ぐのに役立ちます。 リージョン エンドポイントでは、地理的な領域でトラフィックを維持することができます。 たとえば、Azure リソースが WestUS2 内にある場合は、すべてのトラフィックが WestUS2 内にとどまります。

ワークロードが Microsoft Azure で実行されていない場合、ワークロードは OAuth 2.0 クライアント資格情報フローで自身を認証する必要があります。

Microsoft Entra ID では、次のクライアント資格情報の種類がサポートされています。

  • 証明書。 ワークロードは、秘密キーを使用してアサーションに署名することで、秘密キーを所有していることを証明します。 秘密キーは Microsoft Entra ID には送信されません。 アサーションのみが送信されます。 クライアント シークレットの代わりに証明書をお勧めします。証明書はセキュリティが強化されており、多くの場合、より適切に管理されるためです。
  • フェデレーション資格情報。 ワークロード ID フェデレーションを使用すると、Microsoft Azure で実行されていないワークロードは、別の ID プロバイダー、GitHub Actions、または Kubernetes クラスターの ID を使用できます。 ワークロードは、証明書資格情報と同じ方法でフェデレーション資格情報のトークンを要求します。 ここでの違いは、署名された JSON Web トークンであるアサーションがフェデレーション ID プロバイダーから取得される点です。
  • クライアント シークレット。 アプリケーション パスワードと呼ばれることもあるクライアント シークレットは、ワークロードが自身を識別するために使用できる文字列値です。 シークレットのテキスト値は、トークン の POST 要求でワークロードから Microsoft Entra ID に送信されます。 クライアント シークレットは、証明書またはワークロード ID フェデレーションよりも安全性が低くなります。 ワークロードでシークレットを使用する場合は、シークレットを管理するためのベスト プラクティスに従ってください。

Microsoft Entra 製品ファミリには、Microsoft Entra ID に加えて、Microsoft Entra ワークロード ID も 含まれています。 Microsoft Entra ワークロード ID には、ワークロードのセキュリティを強化するための次のプレミアム機能があります。

  • 条件付きアクセスでは、ワークロード ID のための場所ベースおよびリスクベースのポリシーがサポートされます。
  • ID 保護は、侵害された資格情報、異常なサインイン、アカウントに対する疑わしい変更のレポートを提供します。
  • アクセス レビューでは、最も重要な特権ロールに焦点を当てて、適切なユーザーに委任するようにレビューします。
  • アプリの正常性に関する推奨事項は、アプリケーション ポートフォリオ内の ID 検疫のギャップに対処し、テナントのセキュリティと回復性の体制を改善する方法を提案します。

ワークロードは、少なくとも 1 時間に 1 回 Microsoft Graph を呼び出す場合、 継続的アクセス評価 (CAE) をサポートできます。 CAE をサポートするには、ワークロードが単一テナント アプリケーションであり、Microsoft Graph にアクセスしているテナントに登録されているアプリである必要があります。 ワークロードがこれらの要件を満たしている場合、実装手順については、このサンプルを参照してください。

次のステップ