User consent settings
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/entra-docs · commit 6018947 · +4 −4 lines · also on GitHub
⋯ 61 unchanged lines
6262
6363
:::zone pivot="ms-powershell"
6464
65
−## Understand authorization and permission grant policies in Microsoft Graph PowerShell
65
+### Understand authorization and permission grant policies in Microsoft Graph PowerShell
6666
6767
To configure user consent settings programmatically using Microsoft Graph PowerShell, it's important to understand the distinction between the tenant-wide **authorization policy** and individual **permission grant policies**. The `authorizationPolicy`, retrieved using [Update-MgPolicyAuthorizationPolicy](/powershell/module/microsoft.graph.identity.signins/update-mgpolicyauthorizationpolicy) governs global settings such as whether users can consent to apps and which permission grant policies are assigned to the default user role. For example, you can disable user consent while still allowing developers to manage permissions for the apps they own by assigning only `ManagePermissionGrantsForOwnedResource.DeveloperConsent` in the `permissionGrantPoliciesAssigned` collection.
6868
69
−On the other hand, the [permissionGrantPolicies](/powershell/module/microsoft.graph.identity.signins/get-mgpolicypermissiongrantpolicy) endpoint, lists all defined consent policies in the tenant. These policies determine the specific types of app permissions that users are allowed to grant—such as low-risk delegated permissions. For instance, a policy like `UserConsentLowRisk` might allow users to consent only to apps that request basic profile information, while a custom policy could restrict consent even further or broaden it for specific user groups.
69
+On the other hand, the [permissionGrantPolicies](/powershell/module/microsoft.graph.identity.signins/get-mgpolicypermissiongrantpolicy) endpoint lists your current permission grant policies. These policies determine what permissions can be granted to applications and under what circumstances. Each policy 'includes' certain conditions, but 'excludes' others. When a user tries to consent to an application, the system checks the permission grant policies to see if any of them apply to the user's request. For example, the low-risk policy would allow users to consent to those permissions configured as 'low risk'. It includes these low-risk policies (as a GUID). In another scenario, if a user tries to consent in a context that matches the 'AdminOnly' policy, they're unable to consent.
7070
7171
> [!NOTE]
7272
> Before updating consent settings with a `Update-MgPolicyPermissionGrantPolicy` command, always retrieve the current `authorizationPolicy` to identify which permission grant policies are already assigned. This ensures you preserve necessary permissions—such as those enabling developers to manage consent for apps they own—and avoid unintentionally removing existing functionality.
⋯ 57 unchanged lines
130130
131131
:::zone pivot="ms-graph"
132132
133
−## Understand authorization and permission grant policies in Microsoft Graph
133
+### Understand authorization and permission grant policies in Microsoft Graph
134134
135135
To configure user consent settings programmatically using Microsoft Graph, it's important to understand the distinction between the tenant-wide **authorization policy** and individual **permission grant policies**. The `authorizationPolicy` (retrieved using `GET https://graph.microsoft.com/v1.0/policies/authorizationPolicy/authorizationPolicy`) governs global settings such as whether users can consent to apps and which permission grant policies are assigned to the default user role. For example, you can disable user consent while still allowing developers to manage permissions for the apps they own by assigning only `ManagePermissionGrantsForOwnedResource.DeveloperConsent` in the `permissionGrantPoliciesAssigned` collection.
136136
137
−On the other hand, the `permissionGrantPolicies` endpoint (`GET https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies`) lists all defined consent policies in the tenant. These policies determine the specific types of app permissions that users are allowed to grant—such as low-risk delegated permissions. For instance, a policy like `UserConsentLowRisk` might allow users to consent only to apps that request basic profile information, while a custom policy could restrict consent even further or broaden it for specific user groups.
137
+On the other hand, the `permissionGrantPolicies` endpoint (`GET https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies`) lists your current permission grant policies. These policies determine what permissions can be granted to applications and under what circumstances. Each policy 'includes' certain conditions, but 'excludes' others. When a user tries to consent to an application, the system checks the permission grant policies to see if any of them apply to the user's request. For example, the low-risk policy would allow users to consent to those permissions configured as 'low risk'. It includes these low-risk policies (as a GUID). In another scenario, if a user tries to consent in a context that matches the 'AdminOnly' policy, they're unable to consent.
138138
139139
> [!NOTE]
140140
> Before updating consent settings with a `PATCH` request, always retrieve the current `authorizationPolicy` to identify which permission grant policies are already assigned. This ensures you preserve necessary permissions—such as those enabling developers to manage consent for apps they own—and avoid unintentionally removing existing functionality.
⋯ 66 unchanged lines
Microsoft's Markdown source from MicrosoftDocs/entra-docs, © Microsoft Corporation, under MIT. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 01:44 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.