4.1 Enterprise Applications, OAuth Permission Grants & Consent Governance

Why Consent Governance Is an Azure Security Problem

Almost every discussion of Azure identity security starts with users, but the fastest-growing attack surface in a mature tenant is applications. An application that holds Mail.ReadWrite application permission can read every mailbox in the organization without any user signing in, without triggering multi-factor authentication (MFA), and without breaking when the compromised user resets their password. AZ-500 tests this under Manage Microsoft Entra application access and managed identities, and the exam consistently rewards the answer that reduces who can consent rather than the answer that adds another authentication control.

An enterprise application in the Microsoft Entra admin center is the tenant-local service principal for an app. The service principal is what holds sign-in policy, user assignments, and the permission grants. The app registration (covered in the next section) is the global identity definition. One application object can have service principals in many tenants; each of those tenants governs its own grants.

---

Delegated Permissions vs Application Permissions

This distinction is the single most tested idea in this objective.

The intersection rule matters. If an app holds delegated Files.ReadWrite.All but the signed-in user is a standard employee, the app can only touch files that employee could already reach. Grant the same app application Files.ReadWrite.All and it reaches every file in the tenant. On a scenario question, "a nightly job with no interactive user" always points to an application permission with admin consent; "the app should only see what the user can see" always points to delegated.

---

The Three Consent Models

Consent is configured under Entra ID > Enterprise applications > Consent and permissions > User consent settings:

1. Do not allow user consent. Only privileged administrators grant permissions. The most restrictive option; expect heavy admin consent request volume.
2. Allow user consent for apps from verified publishers, for selected permissions — Microsoft’s recommended default. Users can self-consent only when the publisher has completed publisher verification (a blue verified badge backed by a Microsoft Partner Network account) and the requested permissions sit in a permission classification you marked Low impact. User.Read, openid, profile, email, and offline_access are the usual low-impact set.
3. Allow user consent for all apps. Every user can grant any delegated permission to any app. This is the configuration that makes the illicit consent grant attack trivial.

Admin consent can be granted per user (consentType: Principal) or tenant-wide using the Grant admin consent button, which writes consentType: AllPrincipals. Tenant-wide consent is invisible to end users — nobody sees a consent prompt again — so it should be treated as a change-controlled action, not a way to silence a prompt.

Admin consent request workflow

Enable Admin consent requests so blocked users can file a request instead of finding a workaround. You designate reviewers (users, groups, or role holders), set a request expiration, and choose whether reviewers receive email. Reviewers see the requesting user, the app, the exact permissions, and the publisher, then approve or deny in one place. This converts shadow IT into an auditable queue.

---

Restricting Who Can Use an Approved App

Consent decides what the app can do. Two other controls decide who can use it:

• Assignment required (User assignment required = Yes) on the enterprise application. When set, only users and groups on the Users and groups tab can sign in. Anyone else gets AADSTS50105. This is the control for "the finance app must be usable only by the finance group".
• Conditional Access targeting the app. Enterprise applications are first-class Conditional Access targets, so you can demand phishing-resistant MFA, a compliant device, or a named location specifically for one high-value app.

Also disable an application quickly by setting Enabled for users to sign-in = No on the service principal; this stops new tokens without deleting grants you may need for forensics.

---

The Illicit Consent Grant Attack

An attacker registers an app with a plausible name, phishes a link, and the victim clicks Accept on a real Microsoft consent page. No credential is stolen. The attacker now holds a refresh token with the consented scopes.

Why it is dangerous:

• It survives a password reset and, because the token was legitimately issued, it survives MFA enforcement.
• Revoking the user’s sessions is not enough — you must delete the permission grant on the service principal.

Detection and response:

1. Hunt the Entra audit log for the Consent to application operation and inspect the ConsentContext / permission list.
2. Enumerate grants with Microsoft Graph PowerShell: Get-MgOauth2PermissionGrant and Get-MgServicePrincipalAppRoleAssignment.
3. Remove the grant, then disable or delete the service principal, then revoke the user’s refresh tokens.
4. Prevent recurrence by moving user consent to the verified-publisher setting and classifying permissions.

Microsoft Defender for Cloud Apps app governance adds continuous policy on OAuth apps (for example, alert when a newly registered app requests high-privilege Graph permissions or shows anomalous data access), which is the enterprise-scale answer when a scenario mentions ongoing monitoring rather than one-time cleanup.