Section purpose

This section builds on the service principal identity model from Section 1 and focuses on what those identities are allowed to do once they authenticate. The goal is to give you a working understanding of OAuth permissions, the admin consent model, common attack techniques that exploit the permission system, and the governance tools available to harden your tenant against them.

Learning Objectives

• How delegated and application permissions differ in blast radius and consent requirement
• How the OAuth consent flow works and where illicit consent grant attacks exploit it
• Why Application Administrator is a privilege escalation path
• How device code phishing, token theft, refresh token abuse, and over-permissioned lateral movement work
• How to use Entra, App Governance, and PowerShell to audit and reduce permission grants

API permissions: delegated versus application

Every permission grant in Microsoft Entra is either delegated or application.

OAuth consent flow

The authorization code flow for delegated access follows this path:

1. User visits the application.
2. App redirects the browser to the Entra authorization endpoint with the requested scopes.
3. User sees a consent prompt listing the publisher name, permission descriptions, and data access summary.
4. User consents (or admin pre-consented on behalf of the organization).
5. Entra issues an authorization code to the redirect URI.
6. App exchanges the code for an access token and, where the flow supports it, a refresh token.
7. App presents the access token as a bearer token to the target API.

Admin consent changes the flow so that one privileged action approves the permission for the entire organization. This removes the per-user consent prompt and grants tenant-wide access.

Static consent declares all required permissions in the app registration upfront. Dynamic consent allows delegated permissions to be requested progressively at runtime - the app can ask for Mail.Read only when the user actually navigates to the email feature. Application permissions cannot use dynamic consent; they are always declared statically and require admin consent.

Illicit consent grant attacks

Consent is also the primary attack vector for OAuth-based phishing. In an illicit consent grant attack:

1. An attacker registers a convincing-looking multi-tenant application.
2. The attacker sends a phishing link to a target user.
3. The user follows the link, reaches a real Entra consent prompt, and approves the permissions.
4. The attacker now has a persistent OAuth token that bypasses MFA because the user already authenticated.
5. The access continues even after the user changes their password, because the consent grant persists independently of the user's credentials.

Tenant controls that defend against this:

• restrict user consent to verified publishers and low-risk permissions only
• disable user consent entirely and require admin approval for all new applications
• enable the admin consent workflow so users can request access without being blocked outright
• use App Governance anomaly detection to alert on suspicious consent patterns

Non-Graph API permissions

Application permissions are not limited to Microsoft Graph. Any OAuth2-enabled API registered in Entra can be listed in an app's permission request. The most dangerous example is the Azure Service Management API:

• https://management.azure.com/ with user_impersonation delegated scope
• grants the application the same Azure subscription management rights as the signed-in user
• includes the ability to create resources, modify RBAC, access Key Vault secrets, and deploy compute

Other non-Graph API scopes frequently seen in tenant permission reviews:

• Office 365 Exchange Online legacy EWS scopes
• Power BI report and dataset access
• Dynamics 365 and Dataverse business data
• Custom APIs built by your organization or third-party vendors

Application Administrator role: privilege escalation risk

The Application Administrator role is the primary delegated control point for managing applications in Entra. It is frequently over-assigned and poorly understood.

What Application Administrators can do:

• create and manage all app registrations and enterprise applications in the tenant
• add credentials (secrets and certificates) to any existing service principal
• grant admin consent for all delegated permissions and all application permissions for non-Microsoft Graph APIs

What they cannot do without a more privileged role:

• grant admin consent for Microsoft Graph application permissions, which requires Global Administrator or Privileged Role Administrator

The privilege escalation path:

An Application Administrator who adds a new credential to a service principal that already holds high-privilege Graph permissions (granted by a Global Administrator) can then authenticate as that service principal and exercise those permissions.

Application Administrator should be treated as a highly privileged role, assigned only through PIM with just-in-time activation, and its credential modification and consent actions should be monitored via audit logs.

Attack patterns targeting the OAuth model

Device code flow phishing

The device code flow is designed for devices that cannot open a browser. An attacker exploits it as follows:

1. Attacker initiates a device code authentication request.
2. Attacker sends the resulting user code to the victim in a phishing message.
3. Victim enters the code at microsoft.com/devicelogin.
4. Attacker receives valid access and refresh tokens without the victim's password or MFA.

Microsoft Threat Intelligence has tracked active campaigns using this technique (Storm-2372, active since 2024).

Defense: block device code flow via Conditional Access authentication flow restrictions for all users except approved narrow scenarios such as conference room devices on a specific named network.

Token theft and pass-the-token attacks

Access tokens stored in browser local storage, environment variables, pipeline logs, or memory can be extracted and replayed from any machine. MFA is not re-prompted because the token is already authenticated.

Defense:

• Entra Token Protection binds tokens to the issuing device via Proof of Possession
• Continuous Access Evaluation enables near-real-time token revocation
• short token lifetimes for service principals reduce the replay window
• never log tokens in pipeline output or debug traces

Refresh token abuse

In delegated scenarios, refresh tokens can have sliding window lifetimes of 24 hours to 90 days. A stolen refresh token can generate new access tokens for persistent access long after the original session ended.

Defense:

• phishing-resistant authentication methods such as FIDO2 passkeys issue non-exportable credentials
• Conditional Access sign-in frequency and persistent browser session policies can limit refresh token lifetime
• Continuous Access Evaluation revokes tokens faster than waiting for natural expiry

Over-permissioned service principal lateral movement

A compromised service principal with Mail.ReadWrite.All can silently read and modify every mailbox in the tenant. A service principal with Files.ReadWrite.All can access every SharePoint file. These are common in enterprise tenants because proof-of-concept apps accumulated high-privilege grants that were never cleaned up.

Discovering stale over-permissioned service principals:

• App Governance in Defender XDR shows last-used date, privilege level, and unused permissions
• Graph API query to find SPs with high-privilege grants and no recent sign-ins - check appRoleAssignments and cross-reference with service principal sign-in logs
• Remediation workflow: assign an owner → reduce scope to least privilege → rotate or remove credentials → set up monitoring alerts

End-to-end OAuth attack chain

The following scenario connects every risk covered in this section into a single coherent attack.

The setup: An app registration called "HR Sync Tool" was created 18 months ago for a proof of concept. A Global Administrator granted it Mail.ReadWrite.All application permission. The developer who created it has left. The app has an active client secret with six months remaining. No owner is assigned.

Step 1 - Credential discovery: The attacker searches GitHub and finds a config file committed by the former developer containing the client secret.

Step 2 - Silent authentication: The attacker authenticates as the service principal using the stolen secret. No MFA fires. No Conditional Access policy applies. The sign-in looks normal.

Step 3 - Silent exfiltration: With Mail.ReadWrite.All, the attacker silently reads email from the CEO, CFO, and Legal team for three weeks. No user is prompted. The access token is continuously re-acquired via client credentials.

Step 4 - Privilege escalation: A second attacker compromises an Application Administrator account via device code phishing. The Application Administrator adds a new credential to an existing service principal that holds RoleManagement.ReadWrite.Directory. The attacker now has effective Global Administrator-equivalent access.

What detection would have looked like:

• Workload ID Premium alert fires on service principal sign-in from an unrecognized IP
• App Governance flags mass mail access from a stale, low-activity service principal
• Sentinel rule triggers on new credential added to a service principal by an Application Administrator
• Defender for Cloud Apps alerts on anomalous data access volume

Permission hardening and governance

Discovering existing permissions

Use the Entra admin center (Enterprise Applications > Permissions) to review delegated and application permissions granted to each enterprise app.

Use Microsoft Defender for Cloud Apps App Governance for a unified dashboard showing:

• all apps with Graph API permissions
• last-used date and privilege level
• unused permissions and over-privilege indicators

Use PowerShell to enumerate permissions at scale:

# Install once on machines that do not already have the required Graph SDK submodules.
# If an older Microsoft.Graph.Authentication version is already loaded in this session,
# start a new pwsh session after installation before you run Connect-MgGraph.
Install-Module Microsoft.Graph.Identity.SignIns,Microsoft.Graph.Applications `
  -Scope CurrentUser `
  -Force `
  -AllowClobber

Import-Module Microsoft.Graph.Identity.SignIns
Import-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.Read.All","DelegatedPermissionGrant.ReadWrite.All"

# Enumerate application permission grants for the disposable demo app created in Step 0.
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $demoSpObjectId

# Enumerate delegated permission grants for the same demo app.
Get-MgOauth2PermissionGrant -Filter "clientId eq '$demoSpObjectId'"

Revoking permissions after consent

Permissions granted via admin consent can be removed without reinstalling the app.

# Remove a specific delegated permission grant.
# Use the disposable demo grant created in Step 0 or another grant ID you already enumerated.
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $demoDelegatedGrant.id

Removing a permission does not revoke existing valid tokens. Token revocation is a separate action.

Entitlement Management for governed API permissions

Microsoft Entra Entitlement Management can manage access packages that include app role assignments. Instead of permanent admin consent grants, you create an access package that:

1. Contains a specific app role assignment (e.g., a custom API role or a Graph application permission via group-based assignment)
2. Requires an approval workflow - the requestor submits a justification, an approver reviews
3. Has a time-bound expiration - the assignment automatically expires after a set period (e.g., 30 days)
4. Supports renewal with re-approval, or auto-expiry if not renewed

This is useful when developers or operators need temporary elevated API access without leaving permanent high-privilege grants in the tenant.

Lifecycle Workflows

Lifecycle Workflows automate identity tasks triggered by employee lifecycle events:

• Joiner: new hire starts → pre-provisioning tasks run before start date (enable account, add to groups, assign licenses, grant access packages)
• Mover: role or department change → update group memberships, adjust access packages, trigger re-certification of existing permissions
• Leaver: offboarding → disable account, remove group memberships, revoke consent grants, block sign-in sessions

Custom task extensions let you call out to Logic Apps or Function Apps when built-in tasks are not sufficient. For example, a Leaver workflow could trigger a Logic App that disables a service principal, removes its credentials, or queues credential rotation work for apps owned by the departing employee. There is no service-principal sign-in-session revoke endpoint in Graph.

This connects the identity governance story back to automation: the managed identities and Graph API calls covered in earlier sections are what power custom Lifecycle Workflow extensions.

Lab readiness notes

Guided lab

Lab goal

Use Graph Explorer to experience delegated versus application-only access, review App Governance for overprivileged applications, revoke a delegated permission grant, and verify a Conditional Access policy blocking device code flow.

Step 0: Prepare a disposable demo app and grants

Use one setup path and keep the variables it creates in the same terminal session. Each example creates a disposable app, a delegated grant, and an application grant so the later steps have predictable objects to inspect and revoke.

Native PowerShell:

$tenantId = "<tenant-id>"

az login --tenant $tenantId
$accessToken = az account get-access-token `
  --resource-type ms-graph `
  --tenant $tenantId `
  --query accessToken `
  -o tsv

$demoName = "Session2-PermissionsDemo-$(Get-Date -Format 'yyyyMMddHHmmss')"
$demoApp = az ad app create --display-name $demoName --sign-in-audience AzureADMyOrg | ConvertFrom-Json
$demoSp = az ad sp create --id $demoApp.appId | ConvertFrom-Json

$demoAppObjectId = $demoApp.id
$demoSpObjectId = $demoSp.id
$signedInUserId = az ad signed-in-user show --query id -o tsv

$graphSp = Invoke-RestMethod `
  -Method Get `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=appId eq '00000003-0000-0000-c000-000000000000'" `
  -Headers @{ Authorization = "Bearer $accessToken" }

$graphSpId = $graphSp.value[0].id

$demoDelegatedGrant = Invoke-RestMethod `
  -Method Post `
  -Uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants" `
  -Headers @{ Authorization = "Bearer $accessToken"; "Content-Type" = "application/json" } `
  -Body (@{
      clientId    = $demoSpObjectId
      consentType = "Principal"
      principalId = $signedInUserId
      resourceId  = $graphSpId
      scope       = "openid profile offline_access User.Read"
  } | ConvertTo-Json)

$demoAppRoleAssignment = Invoke-RestMethod `
  -Method Post `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$demoSpObjectId/appRoleAssignments" `
  -Headers @{ Authorization = "Bearer $accessToken"; "Content-Type" = "application/json" } `
  -Body (@{
      principalId = $demoSpObjectId
      resourceId  = $graphSpId
      appRoleId   = "498476ce-e0fe-48b0-b801-37ba7e2685c6"
  } | ConvertTo-Json)

Graph PowerShell:

# Run once on machines that do not already have the required Graph PowerShell submodules.
Install-Module Microsoft.Graph.Identity.SignIns,Microsoft.Graph.Applications `
  -Scope CurrentUser `
  -Force `
  -AllowClobber

Import-Module Microsoft.Graph.Identity.SignIns
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.ReadWrite.All","Application.Read.All","DelegatedPermissionGrant.ReadWrite.All","AppRoleAssignment.ReadWrite.All","User.Read"

$demoName = "Session2-PermissionsDemo-$(Get-Date -Format 'yyyyMMddHHmmss')"
$demoApp = New-MgApplication -DisplayName $demoName -SignInAudience "AzureADMyOrg"
$demoSp = New-MgServicePrincipal -AppId $demoApp.AppId

$demoAppObjectId = $demoApp.Id
$demoSpObjectId = $demoSp.Id
$signedInUser = Get-MgUser -UserId (Get-MgContext).Account
$graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" | Select-Object -First 1

$demoDelegatedGrant = New-MgOauth2PermissionGrant -BodyParameter @{
    clientId    = $demoSpObjectId
    consentType = "Principal"
    principalId = $signedInUser.Id
    resourceId  = $graphSp.Id
    scope       = "openid profile offline_access User.Read"
}

$demoAppRoleAssignment = New-MgServicePrincipalAppRoleAssignment `
  -ServicePrincipalId $demoSpObjectId `
  -BodyParameter @{
      principalId = $demoSpObjectId
      resourceId  = $graphSp.Id
      appRoleId   = "498476ce-e0fe-48b0-b801-37ba7e2685c6"
  }

Az CLI:

$tenantId = "<tenant-id>"

az login --tenant $tenantId

$demoName = "Session2-PermissionsDemo-$(Get-Date -Format 'yyyyMMddHHmmss')"
$demoApp = az ad app create --display-name $demoName --sign-in-audience AzureADMyOrg | ConvertFrom-Json
$demoSp = az ad sp create --id $demoApp.appId | ConvertFrom-Json

$demoAppObjectId = $demoApp.id
$demoSpObjectId = $demoSp.id
$signedInUserId = az ad signed-in-user show --query id -o tsv
$graphSpId = az rest `
  --method get `
  --uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=appId eq '00000003-0000-0000-c000-000000000000'" `
  --query "value[0].id" `
  --output tsv

$delegatedGrantBodyPath = Join-Path $env:TEMP "session2-delegated-grant.json"
$appRoleAssignmentBodyPath = Join-Path $env:TEMP "session2-app-role-assignment.json"

(@{
    clientId    = $demoSpObjectId
    consentType = "Principal"
    principalId = $signedInUserId
    resourceId  = $graphSpId
    scope       = "openid profile offline_access User.Read"
} | ConvertTo-Json -Compress) | Set-Content -Path $delegatedGrantBodyPath -Encoding ascii

$demoDelegatedGrant = az rest `
  --method post `
  --uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants" `
  --headers "Content-Type=application/json" `
  --body "@$delegatedGrantBodyPath" | ConvertFrom-Json

(@{
    principalId = $demoSpObjectId
    resourceId  = $graphSpId
    appRoleId   = "498476ce-e0fe-48b0-b801-37ba7e2685c6"
} | ConvertTo-Json -Compress) | Set-Content -Path $appRoleAssignmentBodyPath -Encoding ascii

$demoAppRoleAssignment = az rest `
  --method post `
  --uri "https://graph.microsoft.com/v1.0/servicePrincipals/$demoSpObjectId/appRoleAssignments" `
  --headers "Content-Type=application/json" `
  --body "@$appRoleAssignmentBodyPath" | ConvertFrom-Json

Remove-Item $delegatedGrantBodyPath,$appRoleAssignmentBodyPath

Step 1: Sign in to Graph Explorer and review the consent prompt

Entra ID / Graph Explorer:

Review the delegated consent request

1. Open https://developer.microsoft.com/en-us/graph/graph-explorer in a browser.
2. Select Sign in to Graph Explorer.
3. Review the consent prompt: note the app name, publisher, and listed delegated permissions.
4. Accept the consent.

If Graph Explorer is blocked by user-consent policy in your tenant, continue with the disposable demo app and delegated grant from Step 0. The grant object behaves the same for enumeration and revocation.

Step 2: Run delegated Graph calls

Entra ID / Graph Explorer:

Call /me

1. In Graph Explorer, run GET https://graph.microsoft.com/v1.0/me.

Expected: returns your own user object. This is delegated access.

Call /users and expand scope

1. Run GET https://graph.microsoft.com/v1.0/users.
2. If prompted, request the User.Read.All scope and re-run the call.

Expected: the first call returns a 403 Forbidden until the broader delegated scope is consented. After consent, the users call succeeds.

Native PowerShell:

# Reuse the signed-in user token from Step 0.
$headers = @{ Authorization = "Bearer $accessToken" }

Invoke-RestMethod `
  -Method Get `
  -Uri "https://graph.microsoft.com/v1.0/me" `
  -Headers $headers

# This returns 403 unless the current client has User.Read.All consented.
Invoke-RestMethod `
  -Method Get `
  -Uri "https://graph.microsoft.com/v1.0/users" `
  -Headers $headers

Graph PowerShell:

Connect-MgGraph -Scopes "User.Read"
Get-MgUser -UserId "me"

# Reconnect with the broader delegated scope if you want to test directory reads.
Connect-MgGraph -Scopes "User.Read","User.Read.All"
Get-MgUser -Top 5

Az CLI:

az login --tenant $tenantId

az rest `
  --method get `
  --url "https://graph.microsoft.com/v1.0/me"

# This returns 403 unless the current Azure CLI client has User.Read.All consented.
az rest `
  --method get `
  --url "https://graph.microsoft.com/v1.0/users"

These alternate clients use their own app registrations instead of Graph Explorer, but they demonstrate the same delegated model: the token carries scp scopes and stays bounded by user context.

Step 3: Confirm the consent grant in Entra

Entra Portal:

Review the enterprise app permissions

1. Go to the Entra admin center > Enterprise Applications.
2. Search for Graph Explorer to review the delegated grant created in Step 1.
3. Then search for the disposable Session2-PermissionsDemo-* enterprise app from Step 0 and open Permissions.
4. Review the delegated grant on the disposable demo app so the code paths below target the same object.

Record the permission grant IDs you can see.

The code paths below intentionally query the disposable demo app from Step 0 because it gives you a predictable delegated grant ID for enumeration and revocation.

Native PowerShell:

Invoke-RestMethod `
  -Method Get `
  -Uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?`$filter=clientId eq '$demoSpObjectId'" `
  -Headers @{ Authorization = "Bearer $accessToken" }

Graph PowerShell:

Get-MgOauth2PermissionGrant -Filter "clientId eq '$demoSpObjectId'" |
  Select-Object Id, Scope, ConsentType, PrincipalId

Az CLI:

$grants = az rest `
  --method get `
  --uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?`$filter=clientId eq '$demoSpObjectId'" | ConvertFrom-Json

$grants.value | Select-Object id, scope, consentType, principalId

Step 4: Enumerate and revoke a delegated permission grant

Entra Portal:

Refresh the permissions view after revocation

1. Keep the disposable demo app Permissions blade open from Step 3.
2. After you run one of the revocation commands below, refresh the page and verify that the delegated grant disappears.

Native PowerShell:

$grants = Invoke-RestMethod `
  -Method Get `
  -Uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?`$filter=clientId eq '$demoSpObjectId'" `
  -Headers @{ Authorization = "Bearer $accessToken" }

$grants.value | Select-Object id, scope, consentType

# Revoke a specific delegated grant.
# $grantId = $demoDelegatedGrant.id
# Invoke-RestMethod `
#   -Method Delete `
#   -Uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants/$grantId" `
#   -Headers @{ Authorization = "Bearer $accessToken" }

Graph PowerShell:

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "DelegatedPermissionGrant.ReadWrite.All"

$grants = Get-MgOauth2PermissionGrant -Filter "clientId eq '$demoSpObjectId'"
$grants | Select-Object Id, Scope, ConsentType

# Remove the disposable demo grant from Step 0, or another non-essential grant ID you found above.
# Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $demoDelegatedGrant.Id

Az CLI:

$grants = az rest `
  --method get `
  --uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?`$filter=clientId eq '$demoSpObjectId'" | ConvertFrom-Json

$grants.value | Select-Object id, scope, consentType

# Revoke a specific delegated grant.
# $grantId = $demoDelegatedGrant.id
# az rest `
#   --method delete `
#   --uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants/$grantId"

Expected observation: the portal shows the permission gone after the revocation call runs. Existing Graph Explorer or delegated client sessions still work until their access tokens expire, demonstrating that permission revocation is not immediate token revocation.

Step 5: Review App Governance for overprivileged apps

Defender Portal:

Filter for high-privilege application permissions

1. Open Microsoft Defender XDR.
2. Navigate to Cloud Apps > App Governance.
3. Filter to apps with Mail.ReadWrite.All or Files.ReadWrite.All application permissions.
4. Review the last-used date, owner status, and permission level.

Expected: identify apps that are inactive, unowned, or holding high-privilege permissions that exceed their apparent purpose. This step is intentionally portal-first because App Governance is the purpose-built investigation surface.

Step 6: Verify Conditional Access blocking device code flow

Entra Portal:

Review or create a report-only policy

1. Go to Protection > Conditional Access > Policies.
2. Locate or create a policy that targets all users and blocks the device code authentication flow.
3. Ensure the policy excludes your break-glass or admin account before enabling it.
4. Confirm the policy is set to Report-only mode initially.

Expected: the policy appears in the list. In Report-only mode, sign-in logs show what would have been blocked without affecting current sessions.

Native PowerShell:

# Create a CA policy blocking device code flow (Report-only)
# Requires Security Administrator or Conditional Access Administrator.
# Replace the excluded user with a real break-glass account before using this outside a lab.
$policyBody = @{
    displayName = "Block Device Code Flow"
    state       = "enabledForReportingButNotEnforced"
    conditions  = @{
        clientAppTypes = @("all")
        applications   = @{
            includeApplications = @("All")
        }
        users          = @{
            includeUsers = @("All")
            excludeUsers = @("<break-glass-user-id>")
        }
        authenticationFlows = @{
            transferMethods = "deviceCodeFlow"
        }
    }
    grantControls = @{
        operator        = "OR"
        builtInControls = @("block")
    }
} | ConvertTo-Json -Depth 6

Invoke-RestMethod `
  -Method Post `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
  -Headers @{ Authorization = "Bearer $accessToken"; "Content-Type" = "application/json" } `
  -Body $policyBody

Graph PowerShell:

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    displayName = "Block Device Code Flow"
    state       = "enabledForReportingButNotEnforced"
    conditions  = @{
        clientAppTypes = @("all")
        applications   = @{
            includeApplications = @("All")
        }
        users          = @{
            includeUsers = @("All")
            excludeUsers = @("<break-glass-user-id>")
        }
        authenticationFlows = @{
            transferMethods = "deviceCodeFlow"
        }
    }
    grantControls = @{
        operator        = "OR"
        builtInControls = @("block")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Az CLI:

$policyBodyPath = Join-Path $env:TEMP "session2-device-code-policy.json"

(@{
    displayName = "Block Device Code Flow"
    state       = "enabledForReportingButNotEnforced"
    conditions  = @{
        clientAppTypes = @("all")
        applications   = @{
            includeApplications = @("All")
        }
        users          = @{
            includeUsers = @("All")
            excludeUsers = @("<break-glass-user-id>")
        }
        authenticationFlows = @{
            transferMethods = "deviceCodeFlow"
        }
    }
    grantControls = @{
        operator        = "OR"
        builtInControls = @("block")
    }
} | ConvertTo-Json -Depth 6) | Set-Content -Path $policyBodyPath -Encoding ascii

az rest `
  --method post `
  --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
  --headers "Content-Type=application/json" `
  --body "@$policyBodyPath"

Remove-Item $policyBodyPath

Step 7: Clean up the disposable demo objects

Native PowerShell:

Invoke-RestMethod `
  -Method Delete `
  -Uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants/$($demoDelegatedGrant.id)" `
  -Headers @{ Authorization = "Bearer $accessToken" }

Invoke-RestMethod `
  -Method Delete `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$demoSpObjectId/appRoleAssignments/$($demoAppRoleAssignment.id)" `
  -Headers @{ Authorization = "Bearer $accessToken" }

# Remove this too if you created the report-only device-code policy in Step 6.
# Invoke-RestMethod `
#   -Method Delete `
#   -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/<policy-id>" `
#   -Headers @{ Authorization = "Bearer $accessToken" }

az ad sp delete --id $demoSpObjectId
az ad app delete --id $demoAppObjectId

Graph PowerShell:

Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All","AppRoleAssignment.ReadWrite.All"

Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $demoDelegatedGrant.Id
Remove-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $demoSpObjectId -AppRoleAssignmentId $demoAppRoleAssignment.Id

# Remove this too if you created the report-only device-code policy in Step 6.
# Remove-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "<policy-id>"

Remove-MgServicePrincipal -ServicePrincipalId $demoSpObjectId
Remove-MgApplication -ApplicationId $demoAppObjectId

Az CLI:

az rest `
  --method delete `
  --uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants/$($demoDelegatedGrant.id)"

az rest `
  --method delete `
  --uri "https://graph.microsoft.com/v1.0/servicePrincipals/$demoSpObjectId/appRoleAssignments/$($demoAppRoleAssignment.id)"

# Remove this too if you created the report-only device-code policy in Step 6.
# az rest `
#   --method delete `
#   --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/<policy-id>"

az ad sp delete --id $demoSpObjectId
az ad app delete --id $demoAppObjectId

Quick recap questions

1. What is the key difference between an scp claim and a roles claim in an access token?
2. Why can an Application Administrator escalate to Global Administrator-equivalent access without having that role?
3. Why does revoking a delegated permission grant not immediately stop an attacker who already has a valid token?
4. What makes device code phishing effective against users who have MFA enrolled?
5. Why should the Azure Service Management API permission be audited separately from Microsoft Graph permissions?

Key reminders

• Application permissions always require admin consent and cover the entire tenant, not one user
• Consent grants persist independently of the user's password
• Application Administrator is a high-privilege role that must be governed with PIM
• Token theft bypasses MFA because the token is already authenticated
• Block device code flow in Conditional Access unless a specific named exception is required
• App Governance is the best tool for cross-app permission visibility at scale

References Appendix

All links below were reviewed on 2026-03-10.

OAuth permissions and consent framework

• Overview of consent and permissions in the Microsoft identity platform
• User and admin consent in Microsoft Entra ID
• Configure user consent settings
• Configure admin consent workflow
• Grant tenant-wide admin consent to an application
• Microsoft Graph permissions reference
• Overview of Microsoft Graph permissions

Illicit consent grant and app governance

• Incident Response Playbook: App consent grant
• Incident Response Playbook: Compromised and malicious applications
• Detect and remediate illicit consent grants
• App Governance in Microsoft Defender for Cloud Apps
• Get started with app governance

Device code flow phishing and token attacks

• Storm-2372 conducts device code phishing campaign (Microsoft Threat Intelligence)
• OAuth 2.0 device authorization grant flow in the Microsoft identity platform
• Restrict authentication flows with Conditional Access
• Entra Token Protection (Proof of Possession)
• Continuous Access Evaluation in Microsoft Entra

Application Administrator role and privilege escalation

• Application Administrator built-in role
• Least privileged roles by task in Microsoft Entra
• Privileged Identity Management for service principals
• Monitor and audit service principal sign-ins

Permission hardening and governance

• Manage app consent policies
• Remove-MgOauth2PermissionGrant (Graph PowerShell)
• Get-MgServicePrincipalAppRoleAssignment (Graph PowerShell)
• Entitlement Management overview
• Lifecycle Workflows overview

Community and MVP references

• Merill Fernando: Understanding OAuth Consent Attacks in Microsoft 365
• Joosua Santasalo: Abusing Application Administrator in Entra ID