SaaS OAuth App Sprawl: Audit and Remediation Guide for Security Teams
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.
Every time an employee clicks Allow on an OAuth consent screen, they grant a third-party app persistent access to corporate data with no expiry, no visibility, and no revocation plan. Across a 500-person organization, that means thousands of authorized apps with scopes ranging from read-only calendar to full mailbox and file write access. When any one of those apps is compromised, your tenant is the blast radius. This guide gives security teams a repeatable process to audit what exists, score risk, revoke dangerous grants, and prevent the cycle from restarting.
Why OAuth Sprawl Is a Tier-1 Threat Vector
OAuth tokens persist indefinitely unless explicitly revoked. They survive password resets. They survive MFA enforcement changes. They are invisible to most SIEM alert rules because they use legitimate API calls rather than credential-based logins. Attackers who compromise a third-party SaaS vendor can pivot directly into your Microsoft 365, Google Workspace, or Slack tenants using tokens that employees granted months or years ago. CISA and the NSA have both called third-party OAuth access a critical blind spot in enterprise identity security.
Step 1: Build a Complete App Inventory
You cannot protect what you cannot see. Start with a full inventory across every platform your organization uses.
Microsoft 365, Enterprise Apps blade
Entra ID > Enterprise Applications > All Applications. Filter Application Type = All and export via Graph API: GET /v1.0/servicePrincipals?$select=displayName,appId,oauth2PermissionScopes,signInAudience. Include delegated AND application permissions.
Google Workspace, Admin SDK
Admin Console > Security > API Controls > App Access Control. Export via gam all users show tokens (GAM tool) or googleapis.admin.reports.activities.list with applicationName=token. Captures all user-granted tokens not surfaced in the admin console.
Slack, Installed Apps API
Workspace Admin > Manage Apps. Use Slack Admin API admin.apps.approved.list for workspace-approved apps and apps.permissions.users.list for individual user installs. Token scopes like files:write and admin:users:write should be immediately flagged.
GitHub, OAuth App inventory
Organization Settings > Third-party access. GitHub CLI: gh api /orgs/{org}/installations --paginate | jq '.[].app_slug'. Also audit personal access tokens (PATs) and fine-grained PATs per user, PATs bypass OAuth consent screens entirely.
Aggregate with a CASB or SSPM
Tools like Adaptive Shield, AppOmni, or Obsidian Security can pull inventory from 100+ SaaS apps into a single pane. If you don't have one, a spreadsheet with columns [platform, app_name, granted_by, scopes, last_used, created_date] is a viable interim step.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Step 2: Score Risk for Every App
Not all OAuth apps are equal. Build a risk matrix using four dimensions: scope sensitivity, app verification status, last-used date, and granting user's role.
Scope sensitivity scoring
High risk (score 3): full_access, mail.readwrite, files.readwrite.all, admin scopes, user impersonation. Medium risk (score 2): mail.read, calendars.readwrite, user.read.all. Low risk (score 1): openid, profile, email, offline_access only. Sum the highest scope present per app.
Verification status
Microsoft marks apps Verified publisher when the developer has confirmed their identity via Partner Center. Unverified apps with high-sensitivity scopes get +2 to risk score. Google OAuth verification policy works similarly.
Inactivity penalty
Apps with no API activity in 90+ days: +1. Apps with no activity in 180+ days: +2. Microsoft Graph provides signInActivity.lastSignInDateTime per service principal. Google Admin Reports API provides lastLoginTime per token grant.
Granting user's role
An OAuth grant from a Global Administrator or someone with access to financial systems carries a higher blast radius. Cross-reference against your privileged identity list and add +2 if they hold elevated roles.
Step 3: Revocation Decision Logic
Apply a consistent policy rather than making case-by-case judgment calls that slow the process down.
Immediate revocation (score 7+, or any of these triggers)
App is unverified AND has write or admin scopes. App last used more than 180 days ago AND has sensitive scopes. App's developer domain is no longer resolvable (DNS NXDOMAIN). App was granted by a former employee. App is not in the business-approved software list.
Revoke with 7-day notice (score 4-6)
Send the granting user an automated email: This application has not been used recently and will be revoked in 7 days unless you respond. If no response, revoke. This prevents business disruption for apps that are still in use but appear dormant.
Retain and document (score 1-3)
Add to approved app registry with owner, business purpose, review date (quarterly for high-scope apps, annually for read-only). Schedule automated re-review using your task management or GRC platform.
Microsoft 365 revocation via Graph API
Revoke individual consent: DELETE /v1.0/users/{userId}/oauth2PermissionGrants/{id}. Revoke all grants for a service principal: POST /v1.0/servicePrincipals/{id}/revokeSignInSessions. Disable the service principal entirely: PATCH /v1.0/servicePrincipals/{id} with {accountEnabled: false}.
Google Workspace revocation via Admin SDK
POST https://admin.googleapis.com/admin/directory/v1/users/{userKey}/tokens/{clientId}/revoke. For bulk revocation: gam all users delete token clientid {appClientId}. Also block future grants: Admin Console > Security > API Controls > Block all third-party app access.
Step 4: Enforce Governance to Prevent Re-Sprawl
Revocation without policy change is a one-time fix. The goal is structural prevention.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Detection: Spotting Active Abuse of OAuth Tokens
Even with a clean inventory, a compromised app could be actively exfiltrating data. Set these detections in your SIEM.
Microsoft Sentinel, unusual OAuth app activity
KQL: CloudAppEvents | where ActionType == "OAuthConsentGranted" | where RawEventData.Scope contains_any ("Mail.ReadWrite", "Files.ReadWrite.All", "user_impersonation") | summarize count() by InitiatingUserOrApp, bin(Timestamp, 1h). Alert on any new grant of these scopes outside business hours.
Microsoft Sentinel, dormant app sudden activity
KQL: let lastSeen = SigninLogs | where AppDisplayName !in (knownActiveApps) | summarize LastSeen=max(TimeGenerated) by AppDisplayName; SigninLogs | join kind=leftouter lastSeen on AppDisplayName | where LastSeen < ago(90d) and TimeGenerated > ago(1h). Dormant app suddenly calling Graph API is a red flag.
Google Workspace, token abuse via Admin Reports
Query Admin Reports API for activity.events.name = TOKEN_ISSUED combined with activity.events.parameters.scope containing https://mail.google.com/. Correlate with Drive activity for the same user within 60 minutes to detect exfiltration chains.
The bottom line
Audit every OAuth grant now. Score by scope and inactivity. Revoke anything you cannot justify. Then lock down consent settings so sprawl cannot silently restart. Every dormant high-scope token is an open door you forgot you left unlocked.
Frequently asked questions
Can OAuth tokens survive a password reset?
Yes. OAuth tokens are issued independently of passwords. A password reset does not revoke previously granted OAuth tokens in Microsoft 365 or Google Workspace unless you explicitly call the token revocation APIs. You must use revokeSignInSessions in Microsoft Graph or the token revocation endpoint in Google Admin SDK to clear tokens after a password reset.
What is the difference between delegated and application permissions in Entra ID?
Delegated permissions act on behalf of a signed-in user and can only do what that user can do. Application permissions act as the app itself with no user context and can operate across your entire tenant. Application permissions with admin consent are significantly higher risk, an app with Mail.Read application permission can read every mailbox in your organization.
How do I find OAuth apps granted by former employees?
Cross-reference your OAuth app inventory (granting user field) against your HR offboarding list or disabled accounts in Entra ID. In Microsoft Graph: GET /v1.0/users/{userId}/oauth2PermissionGrants for disabled accounts. Any token granted by a disabled account should be revoked immediately.
Should I block all user OAuth consent in Microsoft 365?
Blocking all user consent is the most secure posture but creates significant friction. A pragmatic middle ground is to allow user consent only for verified publisher apps requesting low-sensitivity permissions and require admin approval for anything else. Configure the admin consent request workflow so users can self-service request access rather than finding workarounds.
How do I revoke OAuth access for all third-party apps across my Microsoft 365 tenant?
Bulk OAuth revocation in Microsoft 365: use the Microsoft Graph API or Azure AD PowerShell to enumerate and remove service principal OAuth grants. PowerShell command: Get-MgServicePrincipal | Where-Object {$_.Tags -notcontains 'WindowsAzureActiveDirectoryIntegratedApp'} to find third-party apps; then Remove-MgOauth2PermissionGrant for individual grants or Remove-MgServicePrincipalPasswordCredential to revoke app credentials. For emergency response (suspected compromise), use Conditional Access policies to block all non-Microsoft app authentication immediately, then investigate selectively. Microsoft Defender for Cloud Apps provides a UI-based OAuth app governance panel that allows single-click revocation per app.
How should I prioritize OAuth app remediation when I have thousands of grants across my tenant?
Triage by blast radius first, not by count. Start with any app that holds application permissions (not delegated) and has admin consent -- these act without a signed-in user and can access every mailbox or file in your tenant. Next, focus on apps with no verified publisher status that also hold write or impersonation scopes. Dormant apps (no activity in 90 days) with high-sensitivity scopes are your third priority -- they represent open attack surface with no business justification. Use Microsoft Defender for Cloud Apps OAuth app governance to filter on these three criteria simultaneously and export a ranked remediation list. Apps in categories one and two that cannot be traced to an approved business request should be revoked immediately, without a 7-day grace period.
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.