Finding risky OAuth apps and consent grants in Entra ID

Phishing doesn't always target passwords. In a consent phishing (illicit consent grant) attack, a user is tricked into approving an app that asks for permission to read their mail or files. The app then uses its own tokens; changing the user's password or requiring MFA doesn't remove its access. Microsoft describes the pattern and response in detect and remediate illicit consent grants.

Even without an attack, most tenants accumulate apps over the years: trials, integrations nobody uses, tools from former vendors, each still holding the access it was once given.

How app access works

• App registrations are apps defined in your tenant (often by your own developers or IT). Enterprise applications (service principals) are the instances of apps, yours or third-party, that exist in your tenant and hold permissions.
• Delegated permissions let the app act on behalf of a signed-in user, limited to what that user can access. Users can sometimes grant these themselves.
• Application permissions let the app act without a user, usually across the whole tenant (for example, read every mailbox). Only an administrator can grant them.
• Consent can be given by a user for themselves, or by an admin for the whole organization.

M365Assessments itself works this way: customers grant admin consent to our module apps, which use read-only application permissions (the two opt-in modules, Power Platform and SharePoint Advanced, need broader access and are clearly marked). The same review principles apply to us as to any other app, which is why the permissions we request are published with the reason for each.

Step 1: Inventory enterprise apps and their permissions

1. In the Microsoft Entra admin center, open Enterprise applications › All applications and set the application type filter to include all apps, not just enterprise apps.

2. For each app, open Permissions to see admin-consented and user-consented permissions. See review permissions granted to enterprise applications.

3. Note the publisher and whether it's verified, when the app was added, who consented, and when it last signed in (service principal sign-ins appear in the sign-in logs).

For more than a handful of apps, script it with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"
        # Delegated grants (user or admin consent to act as users)
        Get-MgOauth2PermissionGrant -All |
          Select-Object ClientId, ConsentType, PrincipalId, Scope
        # Application permissions granted to each service principal
        Get-MgServicePrincipal -All | ForEach-Object {
          $sp = $_
          Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
            Select-Object @{n='App';e={$sp.DisplayName}}, ResourceDisplayName, AppRoleId
        }

App role IDs map to permission names on the resource's service principal (for Microsoft Graph, its AppRoles list). Export the results and sort by permission.

Step 2: Decide which apps are risky

Focus on the combination of what the app can do and how much you trust it.

High-impact permissions to look for

Delegated grants that include offline_access keep working long after the user signed in, via refresh tokens.

Trust signals

• Is the publisher verified, and do you recognize the company?
• Does anyone in the business know what the app is for, and still use it?
• Does the permission match the purpose? A calendar scheduling tool shouldn't need Mail.ReadWrite.
• Was consent granted by one user shortly after a suspicious email or sign-in?
• Has the app signed in recently? An unused app with broad permissions is pure risk.

Step 3: Check your own app registrations

• Each app registration has at least one current owner.
• Client secrets are short-lived and tracked; certificates or managed identities are preferred. Remove expired and unused credentials.
• Apps that are no longer used are removed. Microsoft Entra recommendations can flag unused applications and expiring credentials.
• Multi-tenant settings are only enabled where the app is meant for other organizations.
• Ordinary users can't register applications unless there's a reason (Users can register applications in user settings).

Step 4: Lock down consent

1. Restrict user consent. In Enterprise applications › Consent and permissions, choose either "Allow user consent for apps from verified publishers, for selected permissions" (and classify only low-risk permissions) or "Do not allow user consent". See configure how users consent to applications.

2. Enable the admin consent workflow so users can request an app and a named reviewer approves or denies it, instead of users being blocked with no route forward. See configure the admin consent workflow.

3. Limit who can grant admin consent. Global Administrators, Privileged Role Administrators, and Application or Cloud Application Administrators (for most permissions) can consent for the organization. Keep those roles few; see Entra ID privileged access.

Step 5: Revoke what you can't justify

1. Remove the grants. On the app's Permissions page, review and revoke user and admin consent, or remove grants with Remove-MgOauth2PermissionGrant and Remove-MgServicePrincipalAppRoleAssignment.

2. Disable sign-in for the app (Properties › Enabled for users to sign in: No) while you investigate, or delete the service principal if it's clearly unwanted.

3. If you suspect abuse, revoke the affected users' sessions, review audit and sign-in logs for the app's activity, and follow your incident process.

Keep watching

• Review high-impact permissions quarterly, alongside privileged role reviews.
• Alert on new admin consent grants and new credentials added to service principals (both appear in the audit log).
• If you have Microsoft Defender for Cloud Apps, app governance adds policies and alerts for unusual app behavior.

Signs of a consent phishing attack

• A user consented to an app they don't remember, shortly after an email that asked them to "review a document" or "enable a feature".
• An unverified publisher with a name that imitates a well-known brand.
• Delegated permissions for mail or files plus offline_access, granted by one user rather than an admin.
• Sign-ins by the app's service principal from unfamiliar locations, or mail rules and forwarding created soon after consent.

If you see these, treat it as an incident: disable the app, revoke its grants and the user's sessions, and check what it accessed in the audit log before deleting anything.

Bringing the business along

Locking down consent changes how people adopt new tools, so explain it before you switch it on. Tell staff that app requests now go through a short approval, name who reviews them and how quickly, and publish a list of apps that are already approved. A fast, visible approval process is what stops people looking for workarounds such as personal accounts.

How M365Assessments helps

The Core module reads app registrations, enterprise applications and consent grants with read-only permissions, and the report lists apps with high-impact permissions, credentials that are expiring or long-lived, and user consent settings, so you can work through them in order. See what we assess, and review our own permissions by module as part of your app review.