Microsoft Graph のアクセス許可の概要
Microsoft ID プラットフォームがアプリに Microsoft クラウド内のデータへのアクセスを承認する前に、アプリに必要な特権を付与する必要があります。 同様に、アプリが Microsoft Graph を介してデータにアクセスすることをMicrosoft ID プラットフォームが承認する前に、アプリに必要な特権を付与する必要があります。
Microsoft Graph を使用してデータにアクセスして操作するために必要な権限をアプリに付与する方法の 1 つは、アプリに Microsoft Graph のアクセス許可を割り当てることです。 もう 1 つの方法は、ロールベースのアクセス制御 (RBAC) システム (Microsoft Entra RBAC など) です。 場合によっては、Microsoft Graph API を介したデータへのアクセスには、Microsoft Graph のアクセス許可と RBAC アクセス許可の両方が必要になる場合があります。
この記事では、Microsoft Graph のアクセス許可について説明し、それらを使用するためのガイダンスを提供します。 Microsoft Graph が公開するアクセス許可の完全な一覧については、 Microsoft Graph のアクセス許可リファレンスを参照してください。
アクセス許可のしくみの詳細については、次のビデオをwatchします。
アクセス許可の種類
Microsoft Graph では、委任されたアクセスとアプリ専用アクセスの 2 つのアクセス シナリオがサポートされています。 委任されたアクセスでは、アプリはサインインしているユーザーの代わりに Microsoft Graph を呼び出します。 アプリのみのアクセスでは、アプリは、サインインしているユーザーなしで、独自の ID で Microsoft Graph を呼び出します。
これらのアクセス シナリオをサポートするために、Microsoft Graph は 委任されたアクセス許可 と アプリケーションのアクセス許可を公開します。
委任されたアクセス許可
委任されたアクセスのシナリオでは、委任されたアクセス許可 ( スコープとも呼ばれます) が使用されます。 これらは、サインインしているユーザーの代わりにアプリケーションが動作できるようにするアクセス許可です。 ただし、アプリケーションは、サインインしているユーザーがアクセスできなかったものにはアクセスできません。
たとえば、アプリケーションには、ユーザーである Tom に代わって Files.Read.All 委任されたアクセス許可が付与されています。 アプリケーションは、Tom が既にアクセスできるorganization内のすべてのファイルのみを読み取ることができます。 Tom は、次のいずれかの方法でアクセス許可を持っているため、ファイルにアクセスできる場合があります。
- Tom は、ファイルを作成または所有しています。
- ファイルは Tom と直接共有されたか、チームまたはグループ メンバーシップを介して間接的に共有されました。
- Tom には、サポートされている RBAC システムを介してアクセス許可が付与されています。
そのため、委任されたシナリオでは、アプリがユーザーに代わって動作する必要がある特権は、アプリに付与されている Microsoft Graph のアクセス許可 と ユーザー自身のアクセス許可によって決まります。
委任されたアクセスシナリオでは、アプリでユーザーが個人の Microsoft アカウント (Outlook.com、職場または学校アカウントなど) でサインインしたり、両方のアカウントの種類を許可したりできます。 委任されたアクセス許可はすべて職場または学校アカウントに対して有効ですが、すべて個人の Microsoft アカウントに対して有効なわけではありません。 個人の Microsoft アカウントに対して有効な委任されたアクセス許可を特定するには、Microsoft Graph のアクセス許可リファレンスを使用します。
ユーザーがアプリにサインインするとき、または場合によっては管理者に委任されたアクセス許可に同意する機会が与えられます。 ユーザーが同意を付与すると、アプリはユーザーのアクセス許可の境界内にあるリソースと API にアクセスできます。
注:
組み込みロールMicrosoft Entra通じて付与されるアクセス許可では、アプリが Microsoft Graph API のみを呼び出すように制限されることはありません。
アプリケーションのアクセス許可
アプリケーションのアクセス許可 ( アプリ ロールとも呼ばれます) は、サインインしているユーザーが存在しないアプリのみのアクセス シナリオで使用されます。 アプリケーションは、アクセス許可が関連付けられている すべての データにアクセスできます。 たとえば、Files.Read.All アプリケーションのアクセス許可を付与されたアプリケーションは、organization内の任意のファイルを読み取ることができます。
サインインしているユーザーなしでリソースと API にアクセスするアプリの場合、管理者は、アプリがテナントにインストールされたとき、またはMicrosoft Entra 管理センターを介してアプリケーションのアクセス許可に同意します。 アプリケーションのアクセス許可に同意できるのは、特権ロール管理者とグローバル管理者のみです。
Microsoft Graph アプリケーションのアクセス許可が割り当てられるとは別に、アプリには、次のいずれかの条件によって必要な特権が付与される場合があります。
- アプリに、管理するリソースの所有権が割り当てられている場合。
- RBAC システムまたはカスタム管理ロールを使用してアプリにアクセス許可が割り当てられている場合。
注:
組み込みロールMicrosoft Entra通じて付与されるアクセス許可では、アプリが Microsoft Graph API のみを呼び出すように制限されることはありません。
委任されたアクセス許可とアプリケーションのアクセス許可の比較
| カテゴリ | 委任されたアクセス許可 | アプリケーションのアクセス許可 |
|---|---|---|
| アプリの種類 | Web アプリ/ モバイル/シングルページ アプリ (SPA) | Web / デーモン |
| アクセス コンテキスト | ユーザーの代わりにアクセスを取得 | ユーザーなしでアクセスを取得 |
| 同意可能なロール | 管理者だけが同意可能 | |
| その他の名前 | ||
| 同意の結果 | oAuth2PermissionGrant オブジェクト | appRoleAssignment オブジェクト |
| サポートされている signInAudience 型 | AzureADMyOrg AzureADMultipleOrgs AzureADandPersonalMicrosoftAccount PersonalMicrosoftAccount |
AzureADMyOrg AzureADMultipleOrgs AzureADandPersonalMicrosoftAccount |
次の図は、委任されたアクセスシナリオとアプリ専用アクセス シナリオでのアプリの特権を示しています。
アクセス許可の名前付けパターン
Microsoft Graph では、ユーザー、グループ、メールなどの Microsoft Graph リソースに対するアプリのアクセスを制御するのに役立つ詳細なアクセス許可が公開されています。 これらのアクセス許可には、次のパターンで名前が付けられます。
{resource}。{operation}。{constraint}
| 値 | 説明 | 例 |
|---|---|---|
{resource} |
アクセス許可がアクセスを許可する Microsoft Graph リソースを参照します。 たとえば、 user リソースです。 |
User、Application、または Group |
{operation} |
リソースによって公開されるデータに対して許可される Microsoft Graph API操作を参照します。 たとえば、読み取り操作専用の Read や、読み取り、作成、更新、削除の操作に ReadWrite します。 |
Read、 ReadBasic、 ReadWrite、 Create、 Manage、または Migrate |
{constraint} |
アプリがディレクトリ内に持つ潜在的なアクセス範囲を決定します。 この値は明示的に宣言することはできません。 宣言されていない場合、既定の制約は、サインインしているユーザーが所有するデータに制限されます。 |
All, AppFolder, OwnedBy, Selected, Shared, Hidden |
例:
- User.Read - サインインしているユーザーに関する情報をアプリで読み取ることができます。
- Application.ReadWrite.All - アプリがテナント内のすべてのアプリケーションを管理できるようにします。
- Application.ReadWrite.OwnedBy - アプリが作成または所有するアプリケーションのみを管理できるようにします。
- Group.Create - アプリケーションで新しいグループを作成できますが、変更または削除することはできません。
- Member.Read.Hidden - アプリが非表示のメンバーシップを読み取ることができます
Microsoft Graph によって公開されるアクセス許可の完全な一覧については、 Microsoft Graph のアクセス許可リファレンスを参照してください。
リソース固有の同意 (RSC) のアクセス許可
RSC は、リソースによって公開されるデータへのスコープ付きアクセスを許可できる承認フレームワークです。 RSC を使用して、承認されたユーザーは、リソースの種類の特定のインスタンスのデータへのアクセス権をアプリに付与できます。 テナント全体のリソースの種類のすべてのインスタンスへのアクセス権をアプリに付与する必要はありません。
RSC のアクセス許可は同意のためにも使用でき、Teams、チャット、メッセージなど、Microsoft Graph で利用できる機能のサブセットでのみサポートされます。 RSC アクセス許可の詳細を確認するか、使用可能な RSC アクセス許可の完全な一覧を確認してください。
アクセスできないメンバー オブジェクトについて、限定された情報が返される
グループなどのコンテナー オブジェクトは、ユーザーやデバイスなど、さまざまな型のメンバーをサポートしています。 適切な権限を持つアプリケーションがコンテナー オブジェクトのメンバーシップを照会すると、 200 OK 応答とオブジェクトのコレクションが受信されます。 ただし、アプリにコンテナー内の特定のオブジェクト型を読み取るアクセス許可がない場合は、その型のオブジェクトが返されますが、情報が限られています(たとえば、オブジェクトの種類と ID のみが返され、その他のプロパティは nullとして示されます。 アプリに読み取りアクセス許可があるオブジェクトの種類に関する完全な情報が返されます。
この原則は、 directoryObject 型のすべてのリレーションシップに適用されます。 たとえば、 /groups/{id}/members、 /users/{id}/memberOf、 me/ownedObjectsなどがあります。
たとえば、グループには、ユーザー、グループ、アプリケーション、サービス プリンシパル、デバイス、連絡先をメンバーとして含めることができます。 アプリには、グループ メンバーの一覧表示に対する GroupMember.Read.All の最小特権アクセス許可が付与されます。 応答オブジェクトでは、返されるすべてのメンバーに対して id プロパティと @odata.type プロパティのみが設定されます。 その他のプロパティは、 nullとして示されます。 この API の場合:
- ユーザーであるグループのメンバーの基本的なプロパティを読み取るために、アプリには少なくとも User.ReadBasic.All アクセス許可が必要です。
- グループであるグループのメンバーの基本的なプロパティを読み取るために、アプリには少なくとも GroupMember.Read.All アクセス許可が必要です。
- デバイスであるグループのメンバーの基本的なプロパティを読み取るために、アプリには少なくとも Device.Read.All アクセス許可が必要です。
- ただし、個々のリソース レベルのアクセス許可の代わりに、アプリに少なくとも Directory.Read.All アクセス許可を割り当てて、 すべてのメンバーの種類のすべてのプロパティを読み取ることができます。
例
要求
GET https://graph.microsoft.com/v1.0/groups/{id}/members
応答
次のオブジェクトは、応答の例です。
{
"@odata.context":"https://graph.microsoft.com/v1.0/$metadata#directoryObjects",
"value":[
{
"@odata.type":"#microsoft.graph.user",
"id":"69d035a3-29c9-469f-809d-d21a4ae69e65",
"displayName":"Adele Vance",
"createdDateTime":"2019-09-18T09:06:51Z",
},
{
"@odata.type":"#microsoft.graph.group",
"id":"c43a7cc9-2d95-44b6-bf6a-6392e41949b4",
"displayName":"All Company",
"description":null,
"createdDateTime":"2019-10-24T01:34:35Z"
},
{
"@odata.type":"#microsoft.graph.device",
"id": "d282309e-f91d-43b6-badb-9e68aa4b4fc8",
"accountEnabled":null,
"deviceId":null,
"displayName":null,
"operatingSystem":null,
"operatingSystemVersion":null
}
]
}
Microsoft Graph のアクセス許可を使用するためのベスト プラクティス
Microsoft Graph では、アプリが機能するために必要なアクセス許可のみを要求できるようにする詳細なアクセス許可が公開されています。 きめ細かいアクセス許可を使用すると、アプリに操作に必要な 最小限のアクセス 許可をアプリに付与することで、アプリにアクセス許可を割り当てて付与するときに最小特権の原則を適用できます。
たとえば、次のような場合があります。
- アプリは、サインインしているユーザーのプロファイル情報のみを読み取る必要があります。 アプリには User.Read アクセス許可のみが必要です。これは、サインインしているユーザーの情報にアクセスするための最小特権アクセス許可です。 アプリに User.ReadWrite アクセス許可を付与すると、アプリはユーザーのプロファイルを更新する必要がないため、特権が過剰になります。
- アプリは、サインインしているユーザーなしでテナント内のグループを読み取る必要があります。 アプリには GroupMember.Read.All アプリケーションアクセス許可のみが必要です。これは、サインインしているユーザーなしでテナント内のグループを読み取るために最低限の特権を持つアクセス許可です。
- アプリは、サインインしているユーザーの予定表の読み取りまたは書き込みを行う必要があります。 アプリは動的ジョブを管理し、ユーザーの Outlook 予定表から同期してアプリを最新の状態に保ち、ユーザーのジョブをスケジュールします。 ユーザーの予定表データを 取得 するには Calendars.Read が必要ですが、スケジュールされたジョブで予定表 を更新するには 、より高い特権を持つ Calendars.ReadWrite が必要です。 この場合、アプリは Calendars.ReadWrite を要求する必要があります。
アプリケーションに必要以上の権限を付与することは、アプリの攻撃対象領域を増やし、データまたは操作への不正で意図しないアクセスに公開する、セキュリティ上の不十分なプラクティスです。 また、必要以上に多くのアクセス許可を要求すると、ユーザーがアプリへの同意を控え、アプリの導入と使用に影響を与える可能性があります。
アプリに Microsoft Graph のアクセス許可を割り当てて付与する場合は、最小特権の原則を適用します。 詳細については、「 最小限の特権を使用してセキュリティを強化する 」および「 アクセス許可と同意を通じて ID をセキュリティで保護するアプリを構築する」を参照してください。
注意して使用するアクセス許可
一部の Microsoft Graph のアクセス許可では、他のアクセス許可よりも幅広いデータまたは操作へのアクセス権が付与されます。 このようなアクセス許可は注意して使用してください。 たとえば、Directory.AccessAsUser.All アクセス許可は、Microsoft Entra ID全体のほぼすべての API 操作へのアクセスを許可する最高の特権委任されたアクセス許可です。 Directory.ReadWrite.All 権限は、特権ランク付けで 2 番目です。 Directory.Read.All は、Microsoft Entra ID リソースに対する最高の特権読み取り専用アクセス許可です。 これらのアクセス許可は、必要な場合にのみ注意して使用する必要があります。 代わりに、常に特権の低いオプションのアクセス許可を使用します。
Microsoft Entra ID リソースに関する API リファレンス ドキュメントでは、これらの高い特権のアクセス許可の一部が、API へのアクセスをサポートするアクセス許可のテーブルから意図的に除外される場合があります。
さらに、グローバル管理者ロールは、Microsoft Entra IDで最高の特権を持つ組み込みロールです。 API リファレンス ドキュメントでは、このロールは、権限の低いロールを優先して API にアクセスするためにサポートされるロールの一覧から意図的に除外されます。
アプリごとの要求されたアクセス許可の制限
Microsoft Entra IDは、クライアント アプリによって要求および同意できるアクセス許可の数を制限します。 これらの制限は、アプリのマニフェストに表示されるアプリのsignInAudience値によって異なります。
| signInAudience | 許可されたユーザー | アプリが要求できるアクセス許可の最大数 | アプリが要求できる Microsoft Graph アクセス許可の最大数 | 1 つの要求で同意できるアクセス許可の最大数 |
|---|---|---|---|---|
| AzureADMyOrg | アプリが登録されている組織のユーザー | 400 | 400 | 約 155 の委任されたアクセス許可と約 300 のアプリケーションのアクセス許可 |
| AzureADMultipleOrgs | 任意のMicrosoft Entra organizationのユーザー | 400 | 400 | 約 155 の委任されたアクセス許可と約 300 のアプリケーションのアクセス許可 |
| PersonalMicrosoftAccount | コンシューマー ユーザー (Outlook.com、Live.com アカウントなど) | 30 | 30 | 30 |
| AzureADandPersonalMicrosoftAccount | コンシューマー ユーザーと任意のMicrosoft Entra organizationのユーザー | 30 | 30 | 30 |
Microsoft Graph を使用してアクセス許可 ID を取得する
Azure CLI、PowerShell、またはインフラストラクチャをコード フレームワークとして使用してアクセス許可を設定するには、名前の代わりに使用するアクセス許可の識別子が必要になる場合があります。 アクセス許可リファレンスには、すべての Microsoft Graph アクセス許可の ID が一覧表示されます。 または、Microsoft Graph の Get servicePrincipal API を使用して、すべての Microsoft Graph アクセス許可に関する情報をプログラムで読み取ることもできます。 次の例は要求を示しています。
GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000003-0000-0000-c000-000000000000')?$select=id,appId,displayName,appRoles,oauth2PermissionScopes,resourceSpecificApplicationPermissions
appRoles、oauth2PermissionScopes、resourceSpecificApplicationPermissions オブジェクトには、アプリケーション、委任されたアクセス許可、およびリソース固有の同意アクセス許可がそれぞれ格納されます。