Uredi

Manage app consent policies

  • Članak

App consent policies are a way to manage the permissions that apps have to access data in your organization. They're used to control what apps users can consent to and to ensure that apps meet certain criteria before they can access data. These policies help organizations maintain control over their data and ensure they only grant access to trusted apps.

In this article, you learn how to manage built-in and custom app consent policies to control when consent can be granted.

With Microsoft Graph and Microsoft Graph PowerShell, you can view and manage app consent policies.

An app consent policy consists of one or more "include" condition sets and zero or more "exclude" condition sets. For an event to be considered in an app consent policy, it must match at least one "include" condition set, and must not match any "exclude" condition set.

Each condition set consists of several conditions. For an event to match a condition set, all conditions in the condition set must be met.

App consent policies where the ID begins with "microsoft-" are built-in policies. Some of these built-in policies are used in existing built-in directory roles. For example, the microsoft-application-admin app consent policy describes the conditions under which the Application Administrator and Cloud Application Administrator roles are allowed to grant tenant-wide admin consent. Built-in policies can be used in custom directory roles and to configure user consent settings, but can't be edited or deleted.

Prerequisites

  • A user or service with one of the following roles:
    • Global Administrator directory role
    • Privileged Role Administrator directory role
    • A custom directory role with the necessary permissions to manage app consent policies
    • The Microsoft Graph app role (application permission) Policy.ReadWrite.PermissionGrant when connecting as an app or a service

To manage app consent policies for applications with Microsoft Graph PowerShell, connect to Microsoft Graph PowerShell.

Connect-MgGraph -Scopes "Policy.ReadWrite.PermissionGrant"

It's a good idea to start by getting familiar with the existing app consent policies in your organization:

  1. List all app consent policies:

    Get-MgPolicyPermissionGrantPolicy | ft Id, DisplayName, Description

  2. View the "include" condition sets of a policy:

    Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "microsoft-application-admin" | fl

  3. View the "exclude" condition sets:

    Get-MgPolicyPermissionGrantPolicyExclude -PermissionGrantPolicyId "microsoft-application-admin" | fl

Follow these steps to create a custom app consent policy:

  1. Create a new empty app consent policy.

    New-MgPolicyPermissionGrantPolicy `
    -Id "my-custom-policy" `
    -DisplayName "My first custom consent policy" `
    -Description "This is a sample custom app consent policy."

  2. Add "include" condition sets.

    # Include delegated permissions classified "low", for apps from verified publishers
New-MgPolicyPermissionGrantPolicyInclude `
    -PermissionGrantPolicyId "my-custom-policy" `
    -PermissionType "delegated" `
    -PermissionClassification "low" `
    -ClientApplicationsFromVerifiedPublisherOnly

    Repeat this step to add more "include" condition sets.

  3. Optionally, add "exclude" condition sets.

    # Retrieve the service principal for the Azure Management API
$azureApi = Get-MgServicePrincipal -Filter "servicePrincipalNames/any(n:n eq 'https://management.azure.com/')"

# Exclude delegated permissions for the Azure Management API
New-MgPolicyPermissionGrantPolicyExclude `
    -PermissionGrantPolicyId "my-custom-policy" `
    -PermissionType "delegated" `
    -ResourceApplication $azureApi.AppId

    Repeat this step to add more "exclude" condition sets.

After creating the app consent policy, you need to assign it to a custom role in Microsoft Entra ID. You then need to assign users to that custom role, which is attached to the app consent policy you created. For more information on how to assign the app consent policy to a custom role, see App consent permissions for custom roles.

The following cmdlet shows how you can delete a custom app consent policy.

   Remove-MgPolicyPermissionGrantPolicy -PermissionGrantPolicyId "my-custom-policy"

To manage app consent policies, sign in to Graph Explorer with one of the roles listed in the prerequisite section.

You need to consent to the Policy.ReadWrite.PermissionGrant permission.

It's a good idea to start by getting familiar with the existing app consent policies in your organization:

  1. List all app consent policies:

    GET /policies/permissionGrantPolicies?$select=id,displayName,description

  2. View the "include" condition sets of a policy:

    GET /policies/permissionGrantPolicies/{ microsoft-application-admin }/includes

  3. View the "exclude" condition sets:

    GET /policies/permissionGrantPolicies/{ microsoft-application-admin }/excludes

Follow these steps to create a custom app consent policy:

  1. Create a new empty app consent policy.

    POST https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies
Content-Type: application/json

{
  "id": "my-custom-policy",
  "displayName": "My first custom consent policy",
  "description": "This is a sample custom app consent policy"
}

  2. Add "include" condition sets.

    Include delegated permissions classified "low" for apps from verified publishers

    POST https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies/{ my-custom-policy }/includes
Content-Type: application/json

{
  "permissionType": "delegated",
  "PermissionClassification": "low",
  "clientApplicationsFromVerifiedPublisherOnly": true
}

    Repeat this step to add more "include" condition sets.

  3. Optionally, add "exclude" condition sets. Exclude delegated permissions for the Azure Management API (appId 46e6adf4-a9cf-4b60-9390-0ba6fb00bf6b)

    POST https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies/my-custom-policy /excludes
Content-Type: application/json

{
  "permissionType": "delegated",
  "resourceApplication": "46e6adf4-a9cf-4b60-9390-0ba6fb00bf6b "
}

    Repeat this step to add more "exclude" condition sets.

After creating the app consent policy, you need to assign it to a custom role in Microsoft Entra ID. You then need to assign users to that custom role, which is attached to the app consent policy you created. For more information on how to assign the app consent policy to a custom role, see App consent permissions for custom roles.

  1. The following shows how you can delete a custom app consent policy.

    DELETE https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies/ my-custom-policy

Warning

Deleted app consent policies cannot be restored. If you accidentally delete a custom app consent policy, you will need to re-create the policy.

Supported conditions

The following table provides the list of supported conditions for app consent policies.

Condition Description
PermissionClassification The permission classification for the permission being granted, or "all" to match with any permission classification (including permissions that aren't classified). Default is "all."
PermissionType The permission type of the permission being granted. Use "application" for application permissions (for example, app roles) or "delegated" for delegated permissions.

Note: The value "delegatedUserConsentable" indicates delegated permissions that aren't configured by the API publisher to require admin consent. This value can be used in built-in permission grant policies, but can't be used in custom permission grant policies. Required.
ResourceApplication The AppId of the resource application (for example, the API) for which a permission is being granted, or "any" to match with any resource application or API. Default is "any."
Permissions The list of permission IDs for the specific permissions to match with, or a list with the single value "all" to match with any permission. Default is the single value "all."
- Delegated permission IDs can be found in the OAuth2Permissions property of the API's ServicePrincipal object.
- Application permission IDs can be found in the AppRoles property of the API's ServicePrincipal object.
ClientApplicationIds A list of AppId values for the client applications to match with, or a list with the single value "all" to match any client application. Default is the single value "all."
ClientApplicationTenantIds A list of Microsoft Entra tenant IDs in which the client application is registered, or a list with the single value "all" to match with client apps registered in any tenant. Default is the single value "all."
ClientApplicationPublisherIds A list of Microsoft Partner Network (MPN) IDs for verified publishers of the client application, or a list with the single value "all" to match with client apps from any publisher. Default is the single value "all."
ClientApplicationsFromVerifiedPublisherOnly Set this switch to only match on client applications with a verified publishers. Disable this switch (-ClientApplicationsFromVerifiedPublisherOnly:$false) to match on any client app, even if it doesn't have a verified publisher. Default is $false.
scopeType The resource scope type the preapproval applies to. Possible values: group for groups and teams, chat for chats, or tenant for tenant-wide access. Required.
sensitivityLabels The sensitivity labels that are applicable to the scope type and aren't preapproved. It allows you to protect sensitive organizational data. Learn about sensitivity labels. Note: Chat resource does not support sensitivityLabels yet.

Next steps

To get help or find answers to your questions: