App Consent Policies and Admin Consent

App consent policies and admin consent are mechanisms in Microsoft Entra ID that govern how applications can access organizational data. When an application requests permissions (e.g., to read user profiles, send mail, or access SharePoint sites), the system must decide whether to allow that access. There are two primary models: - User consent: An individual user can grant permissions to an app, typically during sign-in. This is suitable for low-risk permissions but can lead to oversharing if not controlled. - Admin consent: An administrator grants consent on behalf of the entire organization. This is required for high-risk permissions (e.g., reading all user profiles, accessing mailboxes) and ensures centralized control.

App consent policies allow administrators to define what permissions users can consent to and under what conditions. These policies are part of the broader Identity Governance framework.

When a user authenticates to an app using OAuth 2.0, the app requests specific permissions (scopes) from the Microsoft identity platform. The consent flow proceeds as follows:

1. The app redirects the user to the Microsoft Entra ID authorize endpoint with the requested scopes. 2. The user signs in, and Microsoft Entra ID checks whether the user has already consented to the requested permissions. 3. If not, Microsoft Entra ID evaluates the app consent policy to determine if the user is allowed to consent. - If the policy allows user consent for the requested permissions, the user sees a consent prompt and can approve. - If the policy blocks user consent, the user sees an error message indicating that admin consent is required. 4. If admin consent is required, the app must be granted consent by an administrator. The admin can use the admin consent endpoint or the Azure portal to grant consent.

- Permission types: - Delegated permissions: The app acts on behalf of the signed-in user. The app can access only what the user can access. - Application permissions: The app acts as itself (no signed-in user). These are high-risk permissions (e.g., read all mail in all mailboxes). - Consent types: - Static consent: Specified at app registration; permissions are requested upfront. - Dynamic consent: Requested at runtime using the scope parameter; allows incremental consent. - Default user consent setting: In new tenants, user consent is allowed for all delegated permissions. This is a security risk. - Admin consent required: For application permissions and high-risk delegated permissions (e.g., Mail.ReadWrite, User.Read.All).

App consent policies are configured in the Microsoft Entra admin center under Enterprise applications > Consent and permissions > User consent settings. There are three options: - Allow user consent for apps: Users can consent to any permission (default). - Do not allow user consent: Users cannot consent; all consent must be admin consent. - Allow user consent for apps from verified publishers, for selected permissions: This is the recommended setting. You can define a policy that specifies which permissions are allowed (e.g., low-risk permissions like openid, profile, email, User.Read).

You can also create custom app consent policies using PowerShell or Microsoft Graph. For example, using the Microsoft Graph PowerShell SDK:

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

$params = @{
    displayName = "Allow low-risk permissions"
    description = "Allow user consent for basic profile and email permissions"
    conditions = @{
        clientApplications = @{
            includeAll = $true
        }
        permissions = @{
            includePermissionNames = @("openid", "profile", "email", "User.Read")
        }
    }
    includeAllApplications = $true
}

New-MgPolicyAppConsentPolicy -BodyParameter $params

When an app requires admin consent, an administrator can grant it via: - Azure portal: Navigate to Enterprise applications > select the app > Permissions > Grant admin consent. - Admin consent endpoint: Use a URL like:

https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={app-id}&state=12345&redirect_uri={redirect-uri}

Granting admin consent means that all users in the organization can use the app with the requested permissions. It cannot be partially granted; you must accept all requested permissions or none.

To track consent activity, use: - Microsoft Entra audit logs: Look for activities like "Consent to application" or "Add app role assignment to service principal". - Microsoft 365 Defender: Alerts for risky consent grants. - PowerShell: Use Get-AzureADAuditDirectoryLogs to retrieve consent events.

Assume you want to allow user consent only for basic profile and email permissions, and block everything else. You would: 1. Set user consent to "Allow user consent for apps from verified publishers, for selected permissions". 2. Create a policy that includes only openid, profile, email, User.Read. 3. Any app requesting Mail.Read or Files.Read.All will require admin consent.

This policy can be enforced across all apps or specific apps.

To check current user consent settings:

Get-AzureADMSAuthorizationPolicy | Select-Object DisplayName, UserConsentSettings

To list all consented apps:

Get-AzureADServicePrincipal -All $true | Where-Object {$_.AppRoleAssignmentRequired -eq $true} | Select-Object DisplayName, AppId

A multinational corporation must comply with GDPR and internal data protection policies. They configure app consent policies to block all user consent for any permission that can read or write user data (e.g., User.Read, Mail.Read). Only basic permissions like openid and profile are allowed for user consent. All other permissions require admin consent. The IT security team uses Microsoft Graph to create a custom policy that includes only low-risk permissions from a predefined list. They also set up a workflow using Microsoft Power Automate to notify the security team when an admin consent request is submitted. In production, this reduces the attack surface for consent phishing. A common issue is that users complain they cannot use productivity apps that request User.Read; the solution is to have the app owner request admin consent, which is reviewed and granted if the app is approved.

A growing company with 200 employees uses many third-party SaaS apps. Initially, they left user consent enabled for all permissions. After a security audit, they discovered that several apps had been granted Mail.ReadWrite permissions by users, allowing those apps to read and send email on behalf of users. The IT admin immediately changed the user consent setting to block all user consent and then reviewed all existing consented apps. They revoked consent for high-risk apps and only re-granted admin consent for vetted apps. They now use the 'verified publisher' feature to ensure that only apps from verified publishers can request user consent for low-risk permissions. This approach balances security with usability, but requires regular monitoring of consent requests.

A hospital uses Microsoft 365 and needs to control access to patient health information (PHI). They configure app consent policies to allow user consent only for permissions that do not access PHI (e.g., openid, profile). Any app requesting Mail.Read, Files.Read.All, or User.Read.All requires admin consent. They also use Conditional Access to require multi-factor authentication when accessing apps that have been granted admin consent. The security team regularly audits consent grants using Microsoft 365 Defender and revokes consent for any app that has not been used for 90 days. A challenge is that some clinical apps require Mail.Read to send appointment reminders; these apps are added to an allowlist via a custom policy, and admin consent is granted after a security review.