Microsoft Graph のアクセス許可の概要

Microsoft ID プラットフォームでアプリが Microsoft クラウド内のデータにアクセスすることを承認するには、アプリに必要な特権を付与する必要があります。 同様に、Microsoft ID プラットフォームでアプリが Microsoft Graph 経由でデータにアクセスすることを承認するには、アプリに必要な特権を付与する必要があります。

Microsoft Graph を通じてデータにアクセスして操作するために必要な特権をアプリに付与する 1 つの方法は、 Microsoft Graph のアクセス許可をアプリに割り当てることです。 もう 1 つの方法は、Microsoft Entra RBAC などのロールベースのアクセス制御 (RBAC) システムを使用する方法です。 場合によっては、Microsoft Graph API を使用してデータにアクセスする場合、Microsoft Graph のアクセス許可と RBAC のアクセス許可の両方が必要になる場合があります。

この記事では、Microsoft Graph のアクセス許可について説明し、その使用に関するガイダンスを提供します。 Microsoft Graph が公開するアクセス許可の完全な一覧を確認するには、 Microsoft Graph のアクセス許可リファレンスを参照してください。

アクセス許可のしくみの詳細については、次のビデオをご覧ください。

アクセス許可の種類

Microsoft Graph では、委任アクセスアプリのみのアクセスという 2 つのアクセス シナリオがサポートされています。 代理アクセスでは、アプリはサインイン ユーザーの代わりに Microsoft Graph を呼び出します。 アプリのみのアクセスでは、アプリは、サインイン ユーザーなしで、独自の ID を使用して Microsoft Graph を呼び出します。

このようなアクセス シナリオをサポートするために、Microsoft Graph は 委任されたアクセス許可アプリケーションのアクセス許可を公開しています。

委任されたアクセス許可

委任されたアクセス許可 ( スコープとも呼ばれます) は、委任されたアクセス シナリオで機能します。 これらのアクセス許可により、アプリケーションはサインイン ユーザーに代わって動作します。 ただし、アプリケーションは、サインイン ユーザーがアクセスできなかったものにはアクセスできません。

たとえば、アプリケーションは Files を取得します。Read.All ユーザーの Tom に代わって委任されたアクセス許可。 アプリケーションは、Tom がすでにアクセスできる organization 内のすべてのファイルのみを読み取ることができます。 Tom は次のいずれかの方法でアクセス許可を持っているため、ファイルにアクセスできる可能性があります。

  • Tom がファイルを作成または所有しています。
  • ファイルは Tom と直接共有されたか、チームまたはグループのメンバーシップを通じて間接的に共有されました。
  • トムは、サポートされている RBAC システムを通じてアクセス許可を付与されています。

したがって、委任されたシナリオでは、アプリがユーザーに代わって動作する必要がある権限は、アプリに付与されている Microsoft Graph のアクセス許可 ユーザー自身のアクセス許可によって決まります。

代理アクセスのシナリオでは、アプリによって、ユーザーが個人の Microsoft アカウント (Outlook.com、職場や学校のアカウント、または両方のアカウントの種類) でサインインできる場合があります。 委任されたアクセス許可はすべて職場または学校アカウントに対して有効ですが、すべてが個人の Microsoft アカウントに対して有効であるとは限りません。 個人の Microsoft アカウントに有効な委任されたアクセス許可を特定するには、 Microsoft Graph のアクセス許可リファレンス を使用します。

ユーザーがアプリにサインインすると、そのユーザーまたは場合によっては管理者が、委任されたアクセス許可に同意する機会が与えられます。 同意した場合、アプリはユーザーのアクセス許可の範囲内でリソースと API にアクセスできます。

注:

Microsoft Entra の組み込みロールを通じて付与されたアクセス許可は、アプリが Microsoft Graph API の呼び出しのみに制限されるわけではありません。

アプリケーションのアクセス許可

アプリケーションのアクセス許可 ( アプリ ロールとも呼ばれます) は、サインインしているユーザーが存在しなくても、アプリのみのアクセス シナリオで機能します。 アプリケーションは、アクセス許可が関連付けられている 任意の データにアクセスできます。 たとえば、アプリケーションが Files.Read.All アプリケーション権限は、organization 内の任意のファイルを読み取ることができます。

User.ReadWrite.All アプリケーションのアクセス許可を使用すると、特権管理者ロールが割り当てられたユーザーなど、Microsoft Graph でサポートされている書き込み可能なユーザー プロパティの多くをアプリケーションで更新できます。

アプリケーションのアクセス許可は、アプリケーションがサインイン ユーザーを必要とせずにリソースにアクセスしたり変更したりできるため、高い特権が与えられます。 最小権限の観点からは、アプリケーションの要件を満たしている場合は、委任されたアクセス許可モデルを使用することをお勧めします。

サインインしたユーザーなしでリソースと API にアクセスするアプリの場合、アプリがテナントまたは Microsoft Entra 管理センターを通じてインストールされたときに、管理者はアプリケーションのアクセス許可に同意します。 特権ロール管理者とグローバル管理者のみが、アプリケーションのアクセス許可に同意できます。

Microsoft Graph アプリケーションのアクセス許可が割り当てられることとは別に、次のいずれかの条件によってアプリに必要な特権が付与される場合もあります。

  • 管理するリソースの所有権がアプリに割り当てられたとき。
  • RBAC システムまたはカスタム管理者ロールを介してアプリにアクセス許可が割り当てられている場合。

注:

Microsoft Entra の組み込みロールを通じて付与されたアクセス許可は、アプリが Microsoft Graph API の呼び出しのみに制限されるわけではありません。

委任されたアクセス許可とアプリケーションのアクセス許可の比較

カテゴリ 委任されたアクセス許可 アプリケーションのアクセス許可
アプリの種類 Web アプリ / モバイル / シングルページ アプリ (SPA) Web / デーモン
アクセス コンテキスト ユーザーの代わりにアクセスを取得 ユーザーなしでアクセスを取得
同意可能なロール
  • ユーザーは自分のデータに対して同意可能
  • 管理者はすべてのユーザーに対して同意可能


ユーザーの同意の可用性は、テナントの アプリの同意ポリシーによっても異なります。 既定でアクセス許可に管理者の同意が必要ない場合でも、organization のポリシーによってユーザーの同意が制限されることがあります
管理者だけが同意可能
その他の名前
  • Scopes
  • OAuth2 のアクセス許可
  • アプリの役割
  • アプリのみのアクセス許可
  • 直接アクセスのアクセス許可
  • 同意の結果 oAuth2PermissionGrant オブジェクト appRoleAssignment オブジェクト
    サポートされている signInAudience の種類 AzureADMyOrg
    AzureADMultipleOrgs
    AzureADandPersonalMicrosoftAccount
    PersonalMicrosoftAccount
    AzureADMyOrg
    AzureADMultipleOrgs
    AzureADandPersonalMicrosoftAccount

    次の図は、委任アクセスとアプリのみアクセスのシナリオでのアプリの特権を示しています。

    委任アクセスとアプリのみアクセスのシナリオにおけるアプリケーション特権の図。

    コネクタ エージェント登録のアクセス許可の種類を選択するためのベスト プラクティス

    Microsoft Graph コネクタ エージェントはバックグラウンド サービスとして実行され、Microsoft Graph アプリケーションのアクセス許可が必要です。

    コネクタ エージェントの登録では委任されたアクセス許可がサポートされていないため、アクセス許可が正しく構成されているように見えても、登録エラーが発生します。

    コネクタ シナリオに必要な最小 特権アプリケーションのアクセス許可 を要求し、 テナント全体の管理者の同意 が付与されていることを確認します。

    アクセス許可の名前付けパターン

    Microsoft Graph には、ユーザー、グループ、メールなどの Microsoft Graph リソースへのアプリのアクセスを制御するのに役立つ詳細なアクセス許可が公開されています。 これらのアクセス許可は、名前付けパターンに従います。

    {resource}.{operation}.{constraint}

    説明
    {resource} アクセス許可によってアクセス権が付与される Microsoft Graph リソースを参照します。 たとえば、 user リソースなどです。 UserApplication、または Group
    {operation} リソースによって公開されるデータに対して許可されている Microsoft Graph API 操作を指します。 たとえば、読み取り操作専用の Read 、読み取り、作成、更新、削除操作の ReadWrite などです。 ReadReadBasicReadWriteCreateManage、または 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 アクセス許可は同意に対しても使用でき、Teams、チャット、メッセージなど、Microsoft Graph を通じて使用できる機能のサブセットでのみサポートされます。 詳細については、「 RSC アクセス許可使用可能な RSC アクセス許可の完全な一覧」を参照してください。

    アクセスできないメンバー オブジェクトについて、限定された情報が返される

    グループなどのコンテナー オブジェクトは、ユーザーやデバイスなど、さまざまな型のメンバーをサポートしています。 適切な特権を持つアプリケーションがコンテナー オブジェクトのメンバーシップをクエリすると、 200 OK 応答とオブジェクトのコレクションを受け取ります。 ただし、コンテナー内の特定のオブジェクトの種類を読み取るアクセス許可がアプリにない場合、アプリはその種類のオブジェクトを受け取りますが、情報は限られています。 たとえば、オブジェクトの種類と ID のみが返され、他のプロパティは null として示される場合があります。 アプリは、読み取りアクセス許可を持つオブジェクト タイプに関する完全な情報を受け取ります。

    この原則は、 directoryObject 型のすべてのリレーションシップに適用されます。 例として、 /groups/{id}/members/users/{id}/memberOfme/ownedObjects などがあります。

    たとえば、グループには、ユーザー、グループ、アプリケーション、サービス プリンシパル、デバイス、および連絡先をメンバーとして持つことができます。 アプリには、グループ メンバーを一覧表示するための最小特権の GroupMember.Read.All アクセス許可が付与されます。 応答オブジェクトでは、返されるすべてのメンバーに対して id プロパティと @odata.type プロパティだけが設定されます。 その他のプロパティは null と示されます。 この API の場合、グループのメンバーに詳細情報を返すには、アプリに次の追加のアクセス許可が必要です。

    • ユーザーであるグループのメンバーの基本プロパティを読み取るには、 User.ReadBasic.All が最小特権のアクセス許可です。
    • グループであるグループのメンバーの基本的なプロパティを読み取るには、 GroupMember.Read.All が最小特権アクセス許可です。
    • デバイスであるグループのメンバーの基本プロパティを読み取るには、 Device.Read.All が最小特権アクセス許可です。
    • サービス プリンシパルであるグループのメンバーの基本プロパティを読み取るには、 Application.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 Entra エージェント ID の場合、一部のリスクの高い Microsoft Graph アクセス許可はエージェントに対してグローバルにブロックされ、エージェント ID に付与することはできません。

    ブロックされた Microsoft Graph 委任アクセス許可スコープまたはアプリ ロールをrequiredResourceAccessエントリのresourceAccessコレクションに含めると、要求は HTTP 400 Bad Request応答で拒否され、アクセス許可がブロックされ、エージェント ID に付与できないことを示すエラーが表示されます。

    エージェントに対してブロックされた Microsoft Graph アクセス許可の一覧については、「 エージェントに対してブロックされている Microsoft Graph アクセス許可」を参照してください。

    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
    

    appRolesoauth2PermissionScopesおよびresourceSpecificApplicationPermissionsの各オブジェクトには、アプリケーション、委任された同意、およびリソース固有の同意アクセス許可がそれぞれ格納されます。