Microsoft ID プラットフォームでのアクセス許可と同意の概要
アプリケーションで、メール、予定表データなどの保護されたリソースに "アクセス" するには、リソース所有者の "承認" が必要です。 リソース所有者は、アプリの要求に "同意" すること、または拒否することができます。 これらの基本的な概念を理解すると、ユーザーと管理者から、必要なときに必要なアクセスのみを要求する、より安全で信頼できるアプリケーションを構築できるようになります。
アクセスのシナリオ
アプリケーション開発者は、アプリケーションがデータにアクセスする方法を特定する必要があります。 アプリケーションでは、サインイン ユーザーの代わりに動作する委任アクセス、またはアプリケーションの専用 ID としてのみ動作するアプリ専用のアクセスを使用できます。
委任アクセス (ユーザーの代わりにアクセス)
このアクセス シナリオでは、ユーザーはクライアント アプリケーションにサインインしています。 クライアント アプリケーションは、ユーザーの代わりにリソースにアクセスします。 委任アクセスでは、委任されたアクセス許可が必要です。 クライアントとユーザーの両方に、要求を行うための許可を個別に付与する必要があります。 委任アクセスのシナリオの詳細については、委任アクセスのシナリオに関する記事を参照してください。
クライアント アプリの場合、適切な委任されたアクセス許可を付与する必要があります。 委任されたアクセス許可は、スコープとも呼ばれます。 スコープは、クライアント アプリケーションでユーザーの代わりにアクセスできる対象を表す、特定のリソースのアクセス許可です。 スコープについて詳しくは、「スコープとアクセス許可」を参照してください。
ユーザーの場合、承認は、ユーザーがリソースにアクセスするために付与された特権に基づきます。 たとえば、Microsoft Entra のロールベースのアクセス制御 (RBAC) によって、ディレクトリ リソースにアクセスするための許可をユーザーに付与でき、また Exchange Online の RBAC によって、メールと予定表のリソースにアクセスするための許可をユーザーに付与できます。 アプリケーションの RBAC の詳細については、アプリケーションの RBAC に関する記事を参照してください。
アプリ専用のアクセス (ユーザーが関与しないアクセス)
このアクセス シナリオでは、ユーザーがサインインしていない状態でアプリケーションが単独で動作します。 アプリケーション アクセスは、自動化やバックアップなどのシナリオで使用されます。 このシナリオには、バックグラウンド サービスやデーモンとして実行されるアプリが含まれます。 特定のユーザーをサインインさせたくない場合や、複数のユーザーに対してデータが必要になる場合に適しています。 アプリ専用アクセス シナリオの詳細については、アプリ専用アクセスに関する記事を参照してください。
アプリ専用のアクセスでは、委任されたスコープではなくアプリ ロールが使用されます。 同意によって許可されたアプリ ロールは、アプリケーションのアクセス許可と呼ばれることもあります。 クライアント アプリには、呼び出し先となるリソース アプリの適切なアプリケーション アクセス許可を付与する必要があります。 付与後、クライアント アプリでは、要求されたデータにアクセスできます。 クライアント アプリケーションへのアプリ ロールの割り当てについて詳しくは、「アプリケーションへのアプリ ロールの割り当て」を参照してください。
アクセス許可の種類
委任されたアクセス許可は、委任アクセス シナリオで使用されます。 これらは、ユーザーの代わりにアプリケーションが動作できるようにするアクセス許可です。 アプリケーションでは、サインイン ユーザー自身がアクセスできない対象にはアクセスできません。
たとえば、あるアプリケーションに、ユーザーの代わりに、委任されたアクセス許可 Files.Read.All が付与されているとします。 このアプリケーションでは、ユーザーが個人的にアクセスできるファイルのみを読み取ることができます。
アプリケーションのアクセス許可 (別名: アプリ ロール) は、サインイン ユーザーがいない、アプリのみアクセスするシナリオで使用されます。 アプリケーションは、アクセス許可が関連付けられているすべてのデータにアクセスできます。
たとえば、Microsoft Graph API のアプリケーション アクセス許可 Files.Read.All が付与されたアプリケーションでは、テナント内のすべてのファイルを Microsoft Graph を使用して読み取ることができます。 一般的に、ある API のサービス プリンシパルの管理者または所有者のみが、その API によって公開されるアプリケーションのアクセス許可に同意できます。
委任されたアクセス許可とアプリケーションのアクセス許可の比較
| アクセス許可の種類 | 委任されたアクセス許可 | アプリケーションのアクセス許可 |
|---|---|---|
| アプリの種類 | Web/モバイル/シングルページ アプリ (SPA) | Web/デーモン |
| アクセスのコンテキスト | ユーザーの代理でアクセスを取得する | ユーザーなしでアクセスを取得する |
| 同意できるユーザー | - ユーザーは自分のデータに同意できます - 管理者はすべてのユーザーに同意できます |
管理者のみが同意できます |
| 同意の方法 | - 静的: アプリ登録時に構成されたリスト - 動的: ログイン時に個別のアクセス許可を要求 |
- 静的のみ: アプリ登録時に構成されたリスト |
| その他の名前 | - スコープ - OAuth2 アクセス許可のスコープ |
- アプリ ロール - アプリ専用のアクセス許可 |
| 同意の結果 (Microsoft Graph に固有) | OAuth2PermissionGrant | appRoleAssignment |
承認
アプリケーションにアクセス許可を付与する方法の 1 つは、同意による方法です。 同意とは、アプリケーションが保護されたリソースにアクセスすることを、ユーザーまたは管理者が承認するプロセスです。 たとえば、ユーザーが初めてアプリケーションにサインインしようとしたとき、そのアプリケーションで、ユーザーのプロファイルを表示し、ユーザーのメールボックスの内容を読み取るためのアクセス許可を要求できます。 ユーザーには、同意プロンプトを通じて、アプリが要求しているアクセス許可の一覧が表示されます。 ユーザーに同意プロンプトが表示されるその他のシナリオとしては、次のような場合があります。
- 以前に許可された同意が取り消されたとき。
- サインイン中に特に同意を求めるようにアプリケーションがコーディングされているとき。
- アプリケーションが動的な同意を使って、実行時に必要に応じて新しいアクセス許可を要求する場合。
同意プロンプトの主要な詳細情報は、アプリケーションが必要とするアクセス許可の一覧とパブリッシャー情報です。 同意プロンプトについて、および管理者とエンド ユーザー両方の同意エクスペリエンスについて詳しくは、「アプリケーションの同意エクスペリエンス」を参照してください。
ユーザーの同意
ユーザーの同意は、ユーザーがアプリケーションにサインインしようとしたときに行われます。 ユーザーがサインイン資格情報を指定すると、同意が既に付与されているか、その資格情報が確認されます。 必要なアクセス許可へのユーザーまたは管理者の同意を示すレコードがない場合、ユーザーには同意プロンプトが表示され、要求されたアクセス許可をアプリケーションに付与するように求められます。 場合によっては、管理者がユーザーの代わりに同意する必要があります。
管理者の同意
必要なアクセス許可によっては、一部のアプリケーションでは、管理者が同意を付与することが必要になる場合があります。 たとえば、アプリケーションのアクセス許可と多くの強い権限の委任されたアクセス許可には、管理者のみが同意できます。
管理者は、自分自身または組織全体のために同意を行うことができます。 ユーザーと管理者の同意について詳しくは、「ユーザーと管理者の同意の概要」を参照してください。
認証要求では、同意が付与されていない場合、およびこれらの高い権限のアクセス許可のいずれかが要求された場合、管理者の同意を求められます。
カスタム アプリケーション スコープを含むアクセス許可要求は高い特権とは見なされないため、管理者の同意は必要ありません。
事前承認
事前承認を使用すると、リソース アプリケーションの所有者は、事前承認した同じ一連のアクセス許可については、ユーザーに対して同意プロンプトを表示することなく、それらのアクセス許可を付与できます。 この方法では、事前承認されたアプリケーションは、アクセス許可に同意するようにユーザーに求めません。 リソース所有者は、Azure portal で、または PowerShell と Microsoft Graph などの API を使用してクライアント アプリを事前承認できます。
その他の認可システム
同意フレームワークは、アプリケーションまたはユーザーが保護されたリソースにアクセスすることを認可する 1 つの方法でしかありません。 管理者は、機密情報へのアクセスを許可している他の認可システムを把握しておく必要があります。 Microsoft におけるさまざまな認可システムの例には、Entra 組み込みロール、Azure RBAC、Exchange RBAC、Teams のリソース固有の同意があります。