Lock Down App Consent and Review OAuth Grants in Entra ID

Why this lab matters

When a user clicks Accept on a permissions prompt, an application receives a token that can read mail, files or the directory on that user's behalf. If the app is malicious, the attacker now has access that survives a password change and never triggers MFA. Default settings in many tenants still let any user consent to any app. This lab closes that door and cleans up what is already there.

What you need

• A test tenant and the Global Administrator or Privileged Role Administrator role.
• The Microsoft Graph PowerShell SDK.
• One test user, and one or two enterprise applications with consented permissions. Graph Explorer is an easy one to consent to for test data.

Step 1: Restrict user consent

1. In the Entra admin centre go to Identity, Applications, Enterprise applications, Consent and permissions, User consent settings.
2. Choose Allow user consent for apps from verified publishers, for selected permissions. For the strictest position choose Do not allow user consent.
3. Open Permission classifications and review the low-impact list. Keep it small: openid, profile, email, offline_access and User.Read are the usual set.
4. Save.

Step 2: Turn on the admin consent workflow

1. In the same area open Admin consent settings.
2. Set Users can request admin consent to apps they are unable to consent to to Yes.
3. Add at least two reviewers. Choose people who can judge permissions, not only a shared mailbox.
4. Turn on email notifications and reminders, set the request expiry to 30 days and save.

Test it: sign in as the test user and open an app that needs a permission outside the low-impact list. You should see Approval required with a box to give a reason. The request then appears under Enterprise applications, Admin consent requests.

Step 3: Audit delegated grants

Connect-MgGraph -Scopes "Directory.Read.All", "DelegatedPermissionGrant.Read.All"

$risky = 'Mail.Read','Mail.ReadWrite','Mail.Send','MailboxSettings.ReadWrite',
         'Files.Read.All','Files.ReadWrite.All','Sites.ReadWrite.All',
         'Directory.ReadWrite.All','User.ReadWrite.All','full_access_as_user'

$grants = Get-MgOauth2PermissionGrant -All | ForEach-Object {
  $sp = Get-MgServicePrincipal -ServicePrincipalId $_.ClientId -Property DisplayName, AppOwnerOrganizationId, VerifiedPublisher
  $scopes = $_.Scope.Trim() -split '\s+'
  [pscustomobject]@{
    App        = $sp.DisplayName
    Publisher  = $sp.VerifiedPublisher.DisplayName
    ConsentFor = if ($_.ConsentType -eq 'AllPrincipals') { 'Whole tenant' } else { 'One user' }
    Risky      = ($scopes | Where-Object { $_ -in $risky }) -join ', '
    Scopes     = $scopes -join ', '
    GrantId    = $_.Id
  }
}
$grants | Sort-Object { $_.Risky.Length } -Descending | Format-Table App, Publisher, ConsentFor, Risky
$grants | Export-Csv .\delegated-grants.csv -NoTypeInformation

Read the top of the list first. An app with no verified publisher, consent for one user and mail or file scopes is the classic consent phishing pattern.

Step 4: Audit application permissions

Application permissions act without a user and are often more powerful.

$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graph.Id -All | ForEach-Object {
  $role = $graph.AppRoles | Where-Object Id -eq $_.AppRoleId
  [pscustomobject]@{ App = $_.PrincipalDisplayName; Permission = $role.Value; Granted = $_.CreatedDateTime }
} | Sort-Object App | Format-Table

Question anything ending in .ReadWrite.All, and treat RoleManagement.ReadWrite.Directory and AppRoleAssignment.ReadWrite.All as equivalent to Global Administrator.

Step 5: Remove a risky grant

1. Confirm with the user or owner that the app is not needed.
2. Revoke the grant:

   Connect-MgGraph -Scopes "DelegatedPermissionGrant.ReadWrite.All"
   Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<GrantId from the report>"

3. If the app looks malicious, also open it under Enterprise applications, Properties, and set Enabled for users to sign in to No. Then revoke the affected user's sessions.

Evidence to keep

• Screenshots of the user consent and admin consent settings.
• The delegated grant CSV from before and after.
• One completed admin consent request showing who approved or denied it.

Clean up

Remove the test apps. Leave the consent settings in place in any tenant you care about.