OAuth Consent Grant Audit: Finding Every App With Access to Your Microsoft 365 Tenant
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
OAuth consent grants are the invisible attack surface in most Microsoft 365 environments. Unlike credential theft, which requires capturing a password or session token, consent phishing attacks achieve persistent tenant access through a mechanism that Microsoft itself considers legitimate: a user or administrator clicks Approve on an OAuth authorization request, and the attacking application receives a token that can read email, access files, enumerate users, or perform administrative actions based on the permissions the user granted. The token persists across password resets, multi-factor authentication changes, and even user account disables in some configurations, because the token is bound to the application and the consent grant, not to the user's authentication session. This guide walks through the complete audit methodology: how to enumerate every service principal and consent grant in your tenant using the Graph API, how to identify the grants that represent active risk, how to execute revocation correctly (spoiler: revoking the grant is not the same as invalidating existing tokens), and how to configure tenant-wide policy changes that prevent the next wave of consent phishing attacks.
How OAuth Consent Grants Work in Entra ID
Understanding the three tiers of consent in Entra ID is prerequisite to understanding why consent grants create persistent access risk. User consent is the base tier: an individual user authorizes a third-party application to access their specific mailbox, calendar, and files. The permissions are scoped to that user's data. User consent can be enabled or disabled by tenant policy, and it is enabled by default in most tenant configurations.
Admin consent is the second tier: a Global Administrator or Privileged Role Administrator grants permissions on behalf of all users in the tenant. An admin consent grant means the application can access data from every user in the organization, not just the administrator who performed the consent. Admin consent grants are powerful enough to give a third-party application read access to every email in the organization or write access to every user's files. They are also not prominently surfaced in most security monitoring configurations.
Tenant-wide admin consent is the most dangerous tier: a permission granted at this level typically includes application-level permissions (not delegated permissions), meaning the application can act independently of any specific user session. Application-level Mail.Read with tenant-wide consent means the application can read any mailbox in the tenant at any time without requiring a user to be logged in. This is the permission tier used in the most impactful consent phishing attacks observed in the wild.
The distinction between delegated permissions and application permissions is critical for risk assessment. Delegated permissions are scoped to the signed-in user's access. Application permissions are tenant-wide and operate without user context. A compromised application with delegated Mail.Read can read one user's email. The same application with application-level Mail.Read can read every user's email. These two findings require different response urgency.
Why Consent Phishing Is Highly Effective
Consent phishing attacks succeed because they exploit the legitimate OAuth authorization flow rather than attacking authentication mechanisms. The attack sequence is: attacker registers a malicious application in their own Azure tenant, configures the application with a convincing display name and branding (Microsoft Teams, Zoom, DocuSign, or any trusted brand), sends a phishing link that initiates an OAuth authorization request against the victim's tenant, and waits for a user or administrator to click Approve on the Microsoft-hosted consent dialog. The consent dialog shows the permissions being requested, but most users and many administrators do not read permission descriptions carefully.
The most effective lures combine urgency with plausible business context. Finance-themed lures request SharePoint file permissions to review an invoice. IT-themed lures request User.Read.All to troubleshoot an account sync issue. Executive-themed lures request Mail.Read.Write to configure an executive assistant delegation. Each of these pretexts has a legitimate real-world analog that makes the permission request seem reasonable in context.
Once consent is granted, the attacker uses the OAuth code returned by Entra ID to obtain access tokens and refresh tokens for the consented permissions. Refresh tokens are long-lived (typically 90 days for user accounts, potentially indefinite for application permissions) and are automatically renewed as long as the application continues to authenticate. Resetting the affected user's password does not invalidate the refresh token. Enabling MFA after the fact does not revoke existing tokens. The only mechanism that terminates the attacker's access is explicit token revocation combined with removal of the consent grant, both of which require knowing that the compromise occurred.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Enumerating All Service Principals and Consent Grants via Graph API
The Microsoft Graph API provides the complete picture of OAuth consent grants that the Entra ID portal does not display in a single view. The audit requires querying three primary endpoints: servicePrincipals (the registered applications in your tenant), oauth2PermissionGrants (delegated permission grants), and appRoleAssignments (application permission grants). Each query returns a different slice of the consent grant picture.
The servicePrincipals endpoint returns every application registered in or consented to by your tenant. The query GET /v1.0/servicePrincipals?$select=displayName,appId,createdDateTime,publisherName,verifiedPublisher,servicePrincipalType with $top=999 and pagination returns the full list. The verifiedPublisher field is critical for risk assessment: applications from unverified publishers have not completed Microsoft's publisher verification process and represent a higher risk profile than verified publisher apps.
For each service principal, query the oauth2PermissionGrants endpoint to retrieve delegated permissions: GET /v1.0/oauth2PermissionGrants?$filter=clientId eq '{servicePrincipalId}'. The response includes the scope field, which contains the delegated permissions granted, and the consentType field, which distinguishes AllPrincipals (tenant-wide admin consent) from Principal (individual user consent). For application permissions, query GET /v1.0/servicePrincipals/{id}/appRoleAssignments. The roleId field maps to specific permission types in the Microsoft Graph permissions reference.
The PowerShell approach using the Microsoft.Graph module provides a more accessible workflow for teams without Python API experience: Connect-MgGraph with the appropriate scopes, then Get-MgServicePrincipal and Get-MgOauth2PermissionGrant. The output can be exported to CSV for analysis in Excel or a data analysis tool. The most important columns to review are: application display name, publisher verification status, consent type (user vs. admin), permission scope, and creation date.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Identifying High-Risk Permission Grants
Not all consent grants represent security risk. A productivity app with User.Read permission to display the signed-in user's profile picture is a different risk category from a CRM integration with Mail.ReadWrite.All at the application level. The risk assessment framework for consent grants evaluates three dimensions: permission scope, consent type, and publisher verification status.
Permission scope risk tiers: Application-level permissions are always higher risk than delegated permissions because they operate without user context and typically have tenant-wide access. Within application permissions, the highest-risk categories are: Mail.Read and Mail.ReadWrite (access to all email in the tenant), Files.ReadWrite.All (access to all SharePoint and OneDrive content), User.ReadWrite.All (ability to modify all user accounts including adding authentication methods), and Directory.ReadWrite.All (ability to modify the directory structure including group memberships and role assignments). Any application with these permissions at the application level, especially from an unverified publisher, should be investigated immediately.
Consent type risk: AllPrincipals consent type (tenant-wide admin consent) always represents broader exposure than individual user consent. The administrative grant was made by someone with elevated privileges, meaning either a Global Administrator was socially engineered or a legitimate admin made a grant without fully understanding the permission scope. Both scenarios warrant review.
Publisher verification: Applications from verified publishers have completed an identity verification process with Microsoft. Unverified publishers have not. Unverified publisher apps are not inherently malicious (many legitimate internal enterprise apps are unverified), but the combination of unverified publisher, high-risk permissions, and AllPrincipals consent type is a pattern consistent with consent phishing attacks.
Revocation Workflow: Grant Removal and Token Invalidation Are Separate Steps
The most important operational fact about OAuth consent grant revocation is that removing the consent grant does not invalidate existing access tokens. Tokens issued before the grant revocation continue to work until they expire. For applications with short-lived access tokens (typically 60 to 90 minutes), removing the grant is sufficient because the attacker will not be able to obtain a new token once their refresh token attempts to renew. But revocation of long-lived tokens requires an additional explicit step.
The complete revocation workflow has four steps. First, remove the consent grant itself using the Graph API: DELETE /v1.0/oauth2PermissionGrants/{id} for delegated grants or DELETE /v1.0/servicePrincipals/{id}/appRoleAssignments/{assignmentId} for application role assignments. Second, revoke all outstanding tokens for the application by calling POST /v1.0/servicePrincipals/{id}/invalidateAllRefreshTokens. Third, if the consent grant was user-level, run Revoke-MgUserSignInSession for the affected users to invalidate their session tokens. Fourth, disable the service principal itself if the application should not have any access: PATCH /v1.0/servicePrincipals/{id} with accountEnabled: false.
For incidents where a consent phishing attack has resulted in confirmed data access (email exfiltration, file access, or administrative actions), complete the revocation steps and then initiate a parallel investigation to determine what the attacker did with the access. Entra ID sign-in logs filtered by the application's appId will show every token issuance and API call the application made. Unified Audit Log search filtered by the application ObjectId will show specific operations on Exchange and SharePoint data.
Tenant-Wide Consent Lockdown Policy
Addressing existing consent grants is a reactive measure. Preventing future consent phishing attacks requires changing the tenant-wide consent policy so that users cannot grant sensitive permissions to unverified publisher applications without administrator review. The most effective policy configuration that balances security with user productivity is: allow user consent for verified publisher apps with low-sensitivity permissions, require administrator approval for all other consent requests.
In Entra ID, navigate to Enterprise Applications > Consent and permissions > User consent settings. The recommended configuration is to allow user consent for apps from verified publishers for classified permissions only, with a custom permission classifier that marks sensitive permissions (any Mail or Files write permission, any directory read or write permission, any User write permission) as requiring admin approval. This configuration means users can install productivity apps from verified publishers without IT friction, while any app requesting sensitive permissions or coming from an unverified publisher triggers an admin approval workflow.
The admin approval workflow in Entra ID sends a notification to designated reviewers when a user request is pending. Configure at least two reviewers (to prevent approval delays if one is unavailable) and set a response time SLA of 24 hours for business requests. The approval workflow creates an audit trail of every consent request and approval decision, which is valuable for both ongoing monitoring and incident investigation.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Ongoing Monitoring for OAuth Token Anomalies
A consent policy change prevents future phishing grants but does not detect abuse by previously granted applications. Ongoing monitoring requires correlating Entra ID sign-in logs with application behavior baselines. The sign-in logs record every token issuance event including the application ID, the user (or no user for application-level tokens), the permissions scope, and the client IP address from which the token was requested.
Anomalous patterns worth alerting on: applications that have been dormant for 90 or more days suddenly issuing tokens, applications accessing data from IP addresses in unexpected geographic regions, applications requesting tokens at unusual hours relative to their historical usage patterns, and applications that normally request delegated tokens suddenly requesting application-level tokens. These patterns do not definitively indicate compromise, but they warrant investigation.
Microsoft Defender for Cloud Apps provides pre-built OAuth app policies that implement many of these detection rules. The Community use rate policy flags applications with very low adoption across the Microsoft customer base, which is a proxy for applications that are novel or unusual. The High error rate policy flags applications generating a high ratio of failed API calls, which can indicate an attacker probing API access. These policies generate alerts that feed into the Defender portal and can be integrated with SIEM platforms via the streaming API.
Entra ID Portal Audit Approach for Smaller Environments
The Graph API query approach is the right methodology for environments with hundreds of service principals, but for smaller organizations or for a quick initial assessment, the Entra ID portal provides a workable interface. Navigate to Microsoft Entra ID, then Enterprise Applications, then All applications, and set the application type filter to All Applications to include third-party and multitenant apps. The resulting list shows every application with a presence in the tenant.
For each application in the high-risk category (those with admin consent grants), click on the application and review the Permissions tab. The Permissions tab shows both granted delegated permissions and granted application permissions, organized by the resource they apply to (Microsoft Graph, Exchange, SharePoint). The Users and Groups tab shows which users have been assigned to the application (for user-assigned apps) or confirms that all users have access (for tenant-wide apps). The Sign-in activity tab shows the last time the application was used, which is critical for identifying dormant applications that should have their grants revoked.
For an initial triage, focus the manual review on: any application with admin consent on high-risk permissions, any application with an AllPrincipals delegated grant from an unverified publisher, and any application that has not shown sign-in activity in over 90 days. These three filters will identify the highest-risk grants in most environments and are achievable through the portal without scripting.
The bottom line
OAuth consent grants are the identity attack surface that persists after every other remediation step. Password resets, MFA enforcement, and conditional access policies do not terminate attacker access obtained through a consent grant unless the grant and all associated tokens are explicitly revoked. The audit process described here, using Graph API enumeration or the Entra ID portal, gives security teams the complete picture of what has been granted. The policy changes, specifically restricting user consent and enabling the admin approval workflow, prevent the next wave of phishing attacks. And the ongoing monitoring through Entra ID sign-in logs and Defender for Cloud Apps provides the detection capability to identify grant abuse before it becomes a full data breach. Run the audit, revoke the grants that should not exist, and lock down the consent policy before your users approve the next convincingly-branded OAuth app.
Frequently asked questions
How do we revoke a consent grant that was made by a user who has since left the organization?
The consent grant persists even after the user account is disabled or deleted. To revoke it, use the Graph API to query oauth2PermissionGrants filtered by the service principal ID of the application (not the deleted user's ID). The grant will still appear because it is associated with the application's service principal, not the user's account. Use DELETE /v1.0/oauth2PermissionGrants/{id} to remove it. If the user's account has been deleted, also run Revoke-MgUserSignInSession with -All parameter before account deletion to terminate any outstanding sessions.
Is it safe to revoke consent grants for applications that are actively in use?
Revoking a consent grant for an application that users depend on will cause that application to stop functioning until consent is re-granted. For legitimate applications that should retain access, the correct approach is to review the permissions, ensure they are appropriate, and document the grant in your application registry rather than revoking it. Revocation should be reserved for applications that have excessive permissions, come from unverified publishers with no business justification, show signs of anomalous behavior, or are no longer actively used by the organization.
Does a service account with Global Administrator privileges that clicked Approve on a phishing consent grant mean we need to assume the entire tenant is compromised?
Yes, a Global Administrator approving admin consent for a malicious application is a worst-case scenario. Application-level permissions granted by a Global Administrator can include Directory.ReadWrite.All, which gives the attacker the ability to create new administrator accounts, modify existing accounts, add authentication methods, and essentially establish persistent administrative access. The incident response actions are: immediately revoke all consent grants made by that administrator, reset the administrator's credentials and all active sessions, audit all administrative actions from that account in the last 90 days using Unified Audit Log, and treat the tenant as potentially fully compromised until the investigation confirms otherwise.
How do we distinguish between legitimate OAuth integrations and consent phishing grants?
The distinguishing characteristics are: verified publisher status (legitimate enterprise software is almost always published by a verified publisher), permission scope proportionality (does the permission match the stated purpose of the application), business justification (can any business unit explain why they consented to this application), and creation date versus first use date (a grant created in response to a phishing email typically shows a very short interval between consent and first token issuance). Build an application registry that documents all approved OAuth integrations, and treat any application not in the registry as requiring investigation regardless of its apparent legitimacy.
Do Microsoft's first-party applications like Teams, Office, and OneDrive also appear in the service principal list?
Yes, Microsoft's own first-party applications appear in the service principal enumeration. These include Teams, Exchange Online, SharePoint Online, the Microsoft Graph Explorer, and dozens of other Microsoft services. You can identify them by their publisherName value of Microsoft Corporation and their verified publisher status. In practice, include them in the initial audit output to confirm they are expected, then exclude them from ongoing risk review by filtering on publisherName not equal to Microsoft Corporation or verified publisher status false. Focus your risk triage on non-Microsoft applications.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.