Azure Active Directory v1.0 エンドポイントでのアクセス許可と同意Permissions and consent in the Azure Active Directory v1.0 endpoint

適用対象:Applies to:
  • Azure AD v1.0 エンドポイントAzure AD v1.0 endpoint

Azure Active Directory (Azure AD) では、OAuth フローと OpenID Connect (OIDC) フローの両方でアクセス許可を広く利用します。Azure Active Directory (Azure AD) makes extensive use of permissions for both OAuth and OpenID Connect (OIDC) flows. アプリが Azure AD から受け取るアクセス トークンには、特定のリソースに関してアプリに付与されたアクセス許可を示す要求が含まれています。When your app receives an access token from Azure AD, the access token will include claims that describe the permissions that your app has in respect to a particular resource.

"スコープ" とも呼ばれる "アクセス許可" を使用すると、リソースに対する承認が容易になります。リソースはアプリが呼び出すどの API に対しても適切なアクセス許可がトークンに含まれていることを確認するだけで済むためです。Permissions, also known as scopes, make authorization easy for the resource because the resource only needs to check that the token contains the appropriate permission for whatever API the app is calling.

アクセス許可の種類Types of permissions

Azure AD では、次の 2 種類のアクセス許可が定義されています。Azure AD defines two kinds of permissions:

  • 委任されたアクセス許可 - サインインしているユーザーが存在するアプリで使用されます。Delegated permissions - Are used by apps that have a signed-in user present. これらのアプリでは、ユーザーまたは管理者がアプリから要求されたアクセス許可に同意すると、API の呼び出し時にサインイン ユーザーとして動作するためのアクセス許可がアプリに委任されます。For these apps, either the user or an administrator consents to the permissions that the app requests and the app is delegated permission to act as the signed-in user when making calls to an API. API によっては、ユーザーが API に直接同意することができない場合があり、代わりに "管理者の同意" が必要になります。Depending on the API, the user may not be able to consent to the API directly and would instead require an administrator to provide "admin consent".
  • アプリケーションのアクセス許可 - サインインしているユーザーが存在しない状態で実行されるアプリ (バックグラウンド サービスまたはデーモンとして実行されるアプリなど) で使用されます。Application permissions - Are used by apps that run without a signed-in user present; for example, apps that run as background services or daemons. 通常、アプリケーションのアクセス許可は非常に強力であり、ユーザー境界を越えるデータや管理者に限定されたデータへのアクセスを許可するため、これらのアクセス許可には管理者だけが同意できます。Application permissions can only be consented by an administrator because they are typically powerful and allow access to data across user-boundaries, or data that would otherwise be restricted to administrators.

有効なアクセス許可は、アプリが API に要求を行うときに付与されるアクセス許可です。Effective permissions are the permissions that your app will have when making requests to an API.

  • 委任されたアクセス許可の場合、アプリの有効なアクセス許可は、(同意によって) アプリに付与されている委任されたアクセス許可と現在サインインしているユーザーの特権の共通部分の最小特権になります。For delegated permissions, the effective permissions of your app will be the least privileged intersection of the delegated permissions the app has been granted (through consent) and the privileges of the currently signed-in user. サインインしているユーザーよりも多くの特権をアプリに付与することはできません。Your app can never have more privileges than the signed-in user. 組織内では、サインインしているユーザーの特権は、ポリシーによって決定することも、1 つ以上の管理者ロールのメンバーシップによって決定することもできます。Within organizations, the privileges of the signed-in user may be determined by policy or by membership in one or more administrator roles. 委任されたアクセス許可に同意できる管理者ロールについては、「Azure AD での管理者ロールのアクセス許可」を参照してください。To learn which administrator roles can consent to delegated permissions, see Administrator role permissions in Azure AD. たとえば、Microsoft Graph で委任されたアクセス許可として User.ReadWrite.All がアプリに付与されているとします。For example, assume your app has been granted the User.ReadWrite.All delegated permission in Microsoft Graph. 通常、このアクセス許可は、組織内のすべてのユーザーのプロファイルを読み取り、更新する権限をアプリに付与します。This permission nominally grants your app permission to read and update the profile of every user in an organization. サインインしているユーザーが全体管理者の場合、アプリは組織内のすべてのユーザーのプロファイルを更新できます。If the signed-in user is a global administrator, your app will be able to update the profile of every user in the organization. ただし、サインインしているユーザーが管理者ロールに属していない場合、アプリが更新できるのは、サインインしているユーザーのプロファイルだけになります。However, if the signed-in user is not in an administrator role, your app will be able to update only the profile of the signed-in user. アプリにはユーザーの代理で動作するためのアクセス許可が付与されていますが、そのユーザーに組織内の他のユーザーのプロファイルを更新する権限がないため、アプリがこれを実行することはできません。It will not be able to update the profiles of other users in the organization because the user that it has permission to act on behalf of does not have those privileges.
  • アプリケーションのアクセス許可の場合、アプリの有効なアクセス許可は、そのアクセス許可が暗示する完全なレベルの権限になります。For application permissions, the effective permissions of your app are the full level of privileges implied by the permission. たとえば、アプリケーションのアクセス許可として User.ReadWrite.All が付与されているアプリは、組織内のすべてのユーザーのプロファイルを更新できます。For example, an app that has the User.ReadWrite.All application permission can update the profile of every user in the organization.

アクセス許可の属性Permission attributes

Azure AD のアクセス許可には、ユーザー、管理者、またはアプリ開発者が、そのアクセス許可によって付与されるアクセスの対象について、情報に基づいて判断するのに役立つ多数のプロパティがあります。Permissions in Azure AD have a number of properties that help users, administrators, or app developers make informed decisions about what the permission grants access to.

注意

Azure AD アプリケーションまたはサービス プリンシパルが公開するアクセス許可は、Azure portal または PowerShell を使用して表示できます。You can view the permissions that an Azure AD Application or Service Principal exposes using the Azure portal, or PowerShell. 次のスクリプトを実行して、Microsoft Graph で公開されているアクセス許可を表示してみてください。Try this script to view the permissions exposed by Microsoft Graph.

Connect-AzureAD

# Get OAuth2 Permissions/delegated permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").OAuth2Permissions

# Get App roles/application permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles
プロパティ名Property name 説明Description Example
ID このアクセス許可を一意に識別する GUID 値です。Is a GUID value that uniquely identifies this permission. 570282fd-fa5c-430d-a7fd-fc8dc98a9dca570282fd-fa5c-430d-a7fd-fc8dc98a9dca
IsEnabled このアクセス許可が使用可能かどうかを示します。Indicates whether this permission is available for use. truetrue
Type このアクセス許可にユーザーの同意と管理者の同意のどちらが必要かを示します。Indicates whether this permission requires user consent or admin consent. UserUser
AdminConsentDescription 管理者の同意エクスペリエンスで管理者に表示される説明です。Is a description that's shown to administrators during the admin consent experiences ユーザーのメールボックスのメールを読み取ることをアプリに許可します。Allows the app to read email in user mailboxes.
AdminConsentDisplayName 管理者の同意エクスペリエンスで管理者に表示されるフレンドリ名です。Is the friendly name that's shown to administrators during the admin consent experience. ユーザーのメールの読み取りRead user mail
UserConsentDescription ユーザーの同意エクスペリエンスでユーザーに表示される説明です。Is a description that's shown to users during a user consent experience. ユーザーが自分のメールボックスのメールを読み取ることをアプリに許可します。Allows the app to read email in your mailbox.
UserConsentDisplayName ユーザーの同意エクスペリエンスでユーザーに表示されるフレンドリ名です。Is the friendly name that's shown to users during a user consent experience. メールの読み取りRead your mail
Value OAuth 2.0 認可フローにおいて、アクセス許可の識別に使用される文字列です。Is the string that's used to identify the permission during OAuth 2.0 authorize flows. Value は、完全修飾アクセス許可名を形成するために、アプリ ID URI 文字列と組み合わせることもできます。Value may also be combined with the App ID URI string in order to form a fully qualified permission name. Mail.Read

Azure AD のアプリケーションでは、必要なリソースや API へのアクセス権を取得するために同意を利用します。Applications in Azure AD rely on consent in order to gain access to necessary resources or APIs. 成功を収めるために、アプリが認識しておく必要があると考えられる多くの種類の同意があります。There are a number of kinds of consent that your app may need to know about in order to be successful. アクセス許可を定義する場合は、ユーザーがアプリや API へのアクセス権を取得する方法も理解しておく必要があります。If you are defining permissions, you will also need to understand how your users will gain access to your app or API.

  • 静的なユーザーの同意 - アプリが対話する必要があるリソースを指定すると、OAuth 2.0 認可フローで自動的に発生します。Static user consent - Occurs automatically during the OAuth 2.0 authorize flow when you specify the resource that your app wants to interact with. 静的なユーザーの同意シナリオでは、Azure portal のアプリの構成で、アプリに必要なすべてのアクセス許可が既に指定されている必要があります。In the static user consent scenario, your app must have already specified all the permissions it needs in the app's configuration in the Azure portal. ユーザー (または、必要に応じて管理者) がこのアプリに同意していなかった場合、Azure AD によって、現時点でユーザーに同意を求めるメッセージが表示されます。If the user (or administrator, as appropriate) has not granted consent for this app, then Azure AD will prompt the user to provide consent at this time.

    API の静的セットへのアクセスを要求する Azure AD アプリの登録の詳細をご覧ください。Learn more about registering an Azure AD app that requests access to a static set of APIs.

  • 動的なユーザーの同意 - v2 Azure AD アプリ モデルの機能です。Dynamic user consent - Is a feature of the v2 Azure AD app model. このシナリオでは、アプリは、v2 アプリの OAuth 2.0 認可フローで必要な一連のアクセス許可を要求します。In this scenario, your app requests a set of permissions that it needs in the OAuth 2.0 authorize flow for v2 apps. ユーザーがまだ同意していなかった場合、現時点で同意を求められます。If the user has not consented already, they will be prompted to consent at this time. 動的な同意の詳細については、こちらをご覧ください。Learn more about dynamic consent.

    重要

    動的な同意は便利な場合もありますが、管理者の同意を必要とするアクセス許可の場合、管理者の同意エクスペリエンスで同意する時点でこれらのアクセス許可を把握できないため、大きな問題が生じます。Dynamic consent can be convenient, but presents a big challenge for permissions that require admin consent, since the admin consent experience doesn't know about those permissions at consent time. 管理者特権のアクセス許可が必要な場合、またはアプリが動的な同意を使用する場合は、Azure portal で (管理者の同意が必要なアクセス許可のサブセットだけでなく) すべてのアクセス許可を登録する必要があります。If you require admin privileged permissions or if your app uses dynamic consent, you must register all of the permissions in the Azure portal (not just the subset of permissions that require admin consent). これにより、テナント管理者が、すべてのユーザーを代表して同意できます。This enables tenant admins to consent on behalf of all their users.

  • 管理者の同意 - 特定の高い権限のアクセス許可がアプリに必要な場合に必要となります。Admin consent - Is required when your app needs access to certain high-privilege permissions. 管理者の同意により、管理者は、組織の高い権限が必要なデータにアプリやユーザーがアクセスすることを承認する前に制御を強化できます。Admin consent ensures that administrators have some additional controls before authorizing apps or users to access highly privileged data from the organization. 管理者の同意を付与する方法の詳細については、こちらをご覧ください。Learn more about how to grant admin consent.

ベスト プラクティスBest practices

クライアントのベスト プラクティスClient best practices

  • アプリに必要なアクセス許可だけを要求します。Only request for permissions that your app needs. アプリに付与されているアクセス許可が多すぎると、アプリが侵害された場合に、ユーザー データが公開される危険性があります。Apps with too many permissions are at risk of exposing user data if they are compromised.
  • アプリがサポートするシナリオに基づいて、委任されたアクセス許可とアプリケーション アクセス許可のいずれかを選択します。Choose between delegated permissions and application permissions based on the scenario that your app supports.
    • 呼び出しがユーザーに代わって行われる場合は、常に委任されたアクセス許可を使用します。Always use delegated permissions if the call is being made on behalf of a user.
    • アプリが非対話型で、特定のユーザーに代わって呼び出しを行わない場合にのみ、アプリケーション アクセス許可を使用します。Only use application permissions if the app is non-interactive and not making calls on behalf of any specific user. アプリケーション アクセス許可は高度な特権を持つため、絶対に必要な場合にのみ使用します。Application permissions are highly privileged and should only be used when absolutely necessary.
  • v2.0 エンドポイントに基づくアプリを使用する場合は、常に静的アクセス許可 (アプリケーション登録で指定されるもの) が実行時に要求する動的アクセス許可 (コードで指定され、承認要求のクエリ パラメーターとして送信されるもの) のスーパーセットになるように設定して、管理者の同意などのシナリオが正しく機能するようにします。When using an app based on the v2.0 endpoint, always set the static permissions (those specified in your application registration) to be the superset of the dynamic permissions you request at runtime (those specified in code and sent as query parameters in your authorize request) so that scenarios like admin consent works correctly.

リソース/API のベスト プラクティスResource/API best practices

  • API を公開するリソースでは、保護するデータまたはアクションに固有のアクセス許可を定義します。Resources that expose APIs should define permissions that are specific to the data or actions that they are protecting. このベスト プラクティスに従うと、クライアントには不要なデータへのアクセス許可が付与されなくなり、ユーザーには同意対象のデータに関する十分な情報が提供されるようになります。Following this best practice helps to ensure that clients do not end up with permission to access data that they do not need and that users are well informed about what data they are consenting to.
  • リソースでは、Read アクセス許可と ReadWrite アクセス許可をそれぞれ明示的に定義します。Resources should explicitly define Read and ReadWrite permissions separately.
  • リソースでは、ユーザー境界を越えるデータへのアクセスを許可するすべてのアクセス許可を Admin アクセス許可としてマークします。Resources should mark any permissions that allow access to data across user boundaries as Admin permissions.
  • リソースは Subject.Permission[.Modifier] という名前付けパターンに従う必要があります。このパターンで、Resources should follow the naming pattern Subject.Permission[.Modifier], where:
    • Subject は、利用可能なデータの種類に対応しますSubject corresponds with the type of data that is available

    • Permission は、ユーザーがそのデータに対して行うアクションに対応しますPermission corresponds to the action that a user may take upon that data

    • Modifier は、別のアクセス許可の特殊化を記述するためにオプションで使用されますModifier is used optionally to describe specializations of another permission

      例:For example:

    • Mail.Read - ユーザーにメールの読み取りを許可します。Mail.Read - Allows users to read mail.

    • Mail.ReadWrite - ユーザーにメールの読み取りまたは書き込みを許可します。Mail.ReadWrite - Allows users to read or write mail.

    • Mail.ReadWrite.All - 管理者またはユーザーに、組織内のすべてのメールへのアクセスを許可します。Mail.ReadWrite.All - Allows an administrator or user to access all mail in the organization.