Who can grant an app access to your data?

Who in your tenant can give a third-party app permission to read their mailbox? Unless someone changed it, the answer is any user. By default, Entra lets every user consent to apps for any permission that doesn't require admin consent. Letting an app read your own mailbox is one of those permissions. Letting it read every file in the organization is not.

How a consent grant becomes a breach

User consent is how OAuth apps get delegated permissions without an admin involved, and it's also how illicit consent grant attacks work. A convincing app asks for Mail.Read, the user clicks Accept, Entra issues tokens, and the attacker reads mail through the API without ever learning the password. MFA doesn't help, because the user already passed it.

Even Microsoft shutting a malicious app down doesn't end its access at once. When Microsoft disables one, new token and refresh token requests are denied, but the access tokens it already holds stay valid until they expire.

Three settings, one recommended

Under Enterprise apps, in Consent and permissions, Entra offers three positions for user consent.

Microsoft recommends the middle setting. It's only as tight as the permission list behind it, though, because users can consent to whatever you classify as low impact.

Classifications live under Consent and permissions, Permission classifications, and only delegated permissions that don't require admin consent can be classified. Microsoft's own example classifies the four that basic sign-in needs: openid, profile, email, and offline_access. Even those four let an app read the signed-in user's profile and keep that access after the user stops using the app, which is worth knowing before you add more.

One case skips user consent entirely. An app that requires users to be assigned to it needs an administrator's consent, whatever the user consent setting says.

Turn on the admin consent workflow

Whichever setting you choose, turn on the admin consent workflow. A blocked user can request the app, designated reviewers approve or deny it, and you keep a record of who asked for what. Microsoft's documentation adds the details that shape how it runs:

• It's under Enterprise apps, Consent and permissions, Admin consent settings. Turning it on takes a Global Administrator, and it can take up to an hour to start working.
• Reviewers see requests in the admin center and, if you turn on notifications, by email. Requests expire after the number of days you set, and reviewers can get reminders before they do.
• Being a reviewer grants nothing. To approve, a reviewer needs the rights to grant admin consent for that app, and only a Global Administrator can approve a request for Microsoft Graph application permissions.
• Reviewers added later can't act on requests made before they were added, and reviewers you remove still get reminders for requests made while they were on the list.

A new setting doesn't touch old grants

Changing the user consent setting only affects consent from then on. Grants users already made stay in place, with the access they gave, which is why the post ended on a question about reading the list.

In the admin center, each enterprise app's Permissions page shows organization-wide grants on the Admin consent tab and per-user grants on the User consent tab. The portal can revoke the first kind but not the second, which has to come out through Microsoft Graph or PowerShell. For a view across the whole tenant, list the delegated grants directly.

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

# consentType Principal: one user consented for themselves
Get-MgOauth2PermissionGrant -All -Filter "consentType eq 'Principal'" |
  Select-Object ClientId, PrincipalId, Scope

In the tenant

In the 4,300-user tenant I ran, app registrations and API permission grants went through consent policy as part of the zero standing privilege program.

So the question from the post stands: when did you last pull the list of OAuth permission grants in your tenant and read it?