Microsoft Graph のアクセス許可の概要
Microsoft ID プラットフォームがアプリに Microsoft クラウド内のデータへのアクセスを承認する前に、アプリに必要な特権を付与する必要があります。 同様に、アプリが Microsoft Graph を介してデータにアクセスすることをMicrosoft ID プラットフォームが承認する前に、アプリに必要な特権を付与する必要があります。
Microsoft Graph を介してデータにアクセスして操作するために必要な権限をアプリに付与する方法の 1 つは、アプリに Microsoft Graph のアクセス許可を割り当てることです。
この記事では、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 には、 Azure AD RBAC などのロールベースのアクセス制御 (RBAC) システムを通じてアクセス許可が付与されています。
そのため、委任されたシナリオでは、アプリがユーザーに代わって動作する必要がある特権は、アプリに付与されている Microsoft Graph のアクセス許可 と ユーザー自身のアクセス許可によって決まります。
委任されたアクセスシナリオでは、アプリでは、ユーザーが個人の Microsoft アカウント (Outlook.com、職場または学校アカウントなど) でサインインしたり、両方のアカウントの種類を許可したりできます。 委任されたアクセス許可はすべて職場または学校アカウントに対して有効ですが、すべて個人の Microsoft アカウントに対して有効なわけではありません。 Microsoft Graph のアクセス許可リファレンスを使用して、個人の Microsoft アカウントに対して有効な委任されたアクセス許可を特定します。
ユーザーがアプリにサインインするとき、または場合によっては管理者に委任されたアクセス許可に同意する機会が与えられます。 ユーザーが同意を与えた場合、アプリはユーザーのアクセス許可の境界内にあるリソースと API にアクセスできます。
注:
Azure AD 組み込みロールを通じて付与されるアクセス許可では、アプリが Microsoft Graph API のみを呼び出すように制限されることはありません。
アプリケーションのアクセス許可
アプリケーションのアクセス許可 ( アプリ ロールとも呼ばれます) は、サインインしているユーザーが存在しないアプリのみのアクセス シナリオで使用されます。 アプリケーションは、アクセス許可が関連付けられているすべてのデータにアクセスできます。 たとえば、Files.Read.All アプリケーションのアクセス許可を付与されたアプリケーションは、organization内の任意のファイルを読み取ります。
サインインしているユーザーなしでリソースと API にアクセスするアプリの場合、アプリがテナントまたはAzure portalにインストールされている場合、アプリケーションのアクセス許可に管理者が同意できます。 管理者のみがアプリケーションのアクセス許可に同意できます。
Microsoft Graph アプリケーションのアクセス許可が割り当てられるとは別に、アプリには次のいずれかの条件で必要な特権が付与される場合があります。
- アプリに、管理するリソースの所有権が割り当てられている場合。
- アプリに Azure AD の組み込みまたはカスタム管理ロールが割り当てられている場合。
注:
Azure AD 組み込みロールを通じて付与されるアクセス許可では、アプリが 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 のアクセス許可リファレンスを参照してください。
アクセスできないメンバー オブジェクトについて、限定された情報が返される
グループなどのコンテナー オブジェクトは、ユーザーやデバイスなど、さまざまな型のメンバーをサポートしています。 適切な権限を持つアプリケーションがコンテナー オブジェクトのメンバーシップを照会すると、応答とオブジェクトのコレクションを受け取ります 200 OK 。 ただし、アプリにコンテナー内の特定のオブジェクト型を読み取るアクセス許可がない場合は、その型のオブジェクトが返されますが、情報が限られています(たとえば、オブジェクトの種類と ID のみが返され、その他のプロパティは として null示されます)。 アプリに読み取りアクセス許可があるオブジェクトの種類に関する完全な情報が返されます。
この原則は、 directoryObject 型のすべてのリレーションシップに適用されます。 例として、/groups/{id}/members、/users/{id}/memberOf、me/ownedObjects などがあります。
シナリオ例
グループのメンバーは、ユーザー、グループ、デバイスです。 アプリには、Microsoft Graph User.Read.All および Group.Read.All のアクセス許可が付与されています。 アプリは リスト グループ メンバー API を呼び出して、グループのメンバーを取得します。
ユーザーであるグループのメンバーの基本的なプロパティを読み取るために、アプリには少なくとも User.Read.All アクセス許可が必要です。 グループであるグループのメンバーの基本的なプロパティを読み取るために、アプリには少なくとも Group.Read.All アクセス許可が必要です。 デバイスであるグループのメンバーの基本的なプロパティを読み取るために、アプリには少なくとも Device.Read.All アクセス許可が必要です。
アプリには、応答で、グループ内のユーザー オブジェクトとグループ オブジェクトにのみアクセスするアクセス許可がありますが、デバイス オブジェクトにはアクセスできないためです。
- ユーザー および グループ メンバー オブジェクトのすべての基本プロパティが返されます。
- デバイス メンバー オブジェクトの場合、オブジェクトの種類とオブジェクト ID のみが返されますが、他のすべてのプロパティの値は null です。
例
要求
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 アクセス許可を付与すると、アプリはユーザーのプロファイルを更新する必要がないため、特権が過剰になります。
- アプリは、サインインしているユーザーなしでテナント内のグループを読み取る必要があります。 このアプリでは、 Group.Read.All アプリケーションのアクセス許可のみが必要です。これは、サインインしているユーザーなしでテナント内のグループを読み取るために最低限の特権を持つアクセス許可です。
- アプリは、サインインしているユーザーの予定表の読み取りまたは書き込みを行う必要があります。 アプリは動的ジョブを管理し、ユーザーの Outlook 予定表から同期してアプリを最新の状態に保ち、ユーザーのジョブをスケジュールします。 ユーザーの予定表データを 取得 するには Calendars.Read が必要ですが、スケジュールされたジョブで予定表 を更新するには 、より高い特権を持つ Calendars.ReadWrite が必要です。 この場合、アプリは Calendars.ReadWrite を要求する必要があります。
アプリケーションに必要以上の特権を付与することは、アプリをデータまたは操作への未承認の意図しないアクセスに公開するセキュリティの低い方法です。 また、必要以上に多くのアクセス許可を要求すると、ユーザーがアプリへの同意を控え、アプリの導入と使用に影響を与える可能性があります。
アプリに Microsoft Graph のアクセス許可を割り当てて付与する場合は、最小特権の原則を適用します。 詳細については、「最低限の特権の原則によってセキュリティを強化する」を参照してください。
アプリごとの要求されたアクセス許可の制限
Azure AD は、クライアント アプリが要求および同意できるアクセス許可の数を制限します。 これらの制限は、アプリの signInAudience マニフェストに表示される アプリの値によって異なります。
| signInAudience | 許可されたユーザー | アプリが要求できるアクセス許可の最大数 | アプリが要求できる Microsoft Graph アクセス許可の最大数 | 1 つの要求で同意できるアクセス許可の最大数 |
|---|---|---|---|---|
| AzureADMyOrg | アプリが登録されている組織のユーザー | 400 | 400 | 約 155 の委任されたアクセス許可と約 300 のアプリケーションのアクセス許可 |
| AzureADMultipleOrgs | Azure AD 組織のユーザー | 400 | 400 | 約 155 の委任されたアクセス許可と約 300 のアプリケーションのアクセス許可 |
| PersonalMicrosoftAccount | コンシューマー ユーザー (Outlook.com、Live.com アカウントなど) | 30 | 30 | 30 |
| AzureADandPersonalMicrosoftAccount | Azure AD 組織のコンシューマー ユーザーとユーザー | 30 | 30 | 30 |
Microsoft Graph を使用してアクセス許可 ID を取得する
Azure CLI、PowerShell、またはインフラストラクチャをコード フレームワークとして使用してアクセス許可を設定するには、名前の代わりに使用するアクセス許可の識別子が必要な場合があります。
すべての Microsoft Graph アクセス許可の ID を見つけるには、「 すべてのアクセス許可と ID」を参照してください。 または、Microsoft Graph の Get servicePrincipal API を使用して、プログラムでアクセス許可を読み取ることもできます。