SaaS OAuth Token Sprawl: Auditing Connected Apps Before They Become Backdoors
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
Decryption Digest previously published a step-by-step audit procedure for OAuth app grants in Microsoft 365, Entra ID, and Google Workspace, covering how to enumerate, prioritize, and revoke grants in those two platforms using the admin portal, Microsoft Graph API, and PowerShell. That guide answers a narrower question: how do you run a thorough one-time (or quarterly) sweep of the two identity platforms most organizations already govern closely. This guide answers a different, broader question: how do you build a standing program that covers every SaaS platform in the estate, not just the two with mature native admin consoles, and that treats token sprawl as something that regenerates continuously rather than something a single audit clears. Salesforce, Slack, GitHub, Snowflake, HubSpot, and dozens of other platforms each maintain their own independent population of OAuth-connected apps, and a program scoped only to Microsoft 365 and Google Workspace will miss all of them. This guide covers discovery across the full SaaS estate, a risk-scoring model that works across platforms with inconsistent permission taxonomies, a recurring re-certification cadence, and the specific ways connected-app inventories stay incomplete even after the first full pass.
Why Token Sprawl Accumulates and Why It Matters
OAuth token sprawl is not the result of a single bad decision. It is the compounding effect of an OAuth consent flow that most SaaS platforms make available to every user by default. An employee connects a scheduling tool to their calendar, a marketing analyst authorizes a reporting dashboard to read Salesforce data, a developer grants a CI tool access to a GitHub organization, and each of those authorizations creates a standing, token-based access grant that outlives the task it was created for. None of these individual decisions look risky in isolation. The problem is aggregate: across a mid-size organization running dozens of SaaS platforms, the population of connected apps typically numbers in the hundreds, most authorized by users with no security review, many of them abandoned once the employee changes roles or the trial period ends, and none of them showing up in an asset inventory built around managed devices and licensed seats.
The risk this creates is structural, not hypothetical. An OAuth grant authenticates by refresh token, not by the user's password, so it survives a password reset and typically survives an MFA policy change as well. It also does not require the connecting application's vendor to stay trustworthy forever: a legitimate app that is later compromised, sold, or has its own OAuth client secret stolen carries every permission scope it was ever granted into the hands of whoever now controls it. The 2025 Salesloft Drift breach is the clearest recent illustration of the blast radius: attackers compromised OAuth tokens belonging to a single third-party chatbot integration and used them to reach Salesforce, Slack, Google Workspace, and cloud storage environments across more than 700 downstream organizations, none of whom had to make a new mistake for the breach to reach them. The token was already sitting there, doing exactly what it was authorized to do, for an app whose security posture nobody downstream controlled.
Prerequisites
Before starting, confirm the following access and scope. Skipping any of these produces an audit that looks complete but covers only part of the estate.
Admin access to every SaaS platform's app-management console
This means Entra ID Enterprise Applications and Google Workspace API Controls at minimum, plus the connected-app or installed-integration screen for every other platform in scope: Salesforce Connected Apps, Slack App Directory and installed apps, GitHub Organization OAuth Apps and installed GitHub Apps, Snowflake OAuth security integrations, and any other SaaS platform holding sensitive data. If you do not have admin rights to a platform, obtain them or arrange a joint review session with whoever does before starting.
A current inventory of SaaS platforms in use
The connected-app audit is only as complete as the list of platforms you audit. Pull this from your identity provider's SSO application list, your expense and procurement records, and, if available, a CASB or SSPM tool's own SaaS discovery output. A platform missing from this list means every OAuth grant inside it is invisible to the program by definition.
An SSPM tool, or an accepted plan to do without one
A SaaS security posture management (SSPM) tool such as AppOmni, Obsidian Security, or Nudge Security automates discovery and risk-scoring across dozens of platforms from a small number of API connections, which is the only practical way to cover a large SaaS estate on a recurring basis. If budget does not support one yet, plan for a manual, per-platform review using each platform's native admin console and API, understanding that manual coverage will lag an SSPM tool's breadth and will be harder to sustain on a recurring cadence.
An owner and a decision-making authority for revocation
Someone needs the authority to revoke a connected app's access and to own the consequences if that breaks a business workflow. Identify this person or team before the audit surfaces its first contested revocation, not during the argument.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Step 1: Discover Every OAuth-Connected App Across the SaaS Estate
Discovery is the step most programs get wrong, because it is tempting to treat the platforms with the best native tooling (Microsoft 365 and Google Workspace) as a proxy for the whole estate. They are not. Run discovery against every platform identified in the prerequisite inventory.
Enumerate Microsoft 365 and Google Workspace grants
Use the Entra ID Enterprise Applications list and consent audit log, and the Google Workspace Admin console's API Controls > App Access Control screen, to pull every delegated and admin-consented OAuth grant. This is the platform pair with the most mature native tooling; treat it as the baseline, not the finish line. For the full enumeration procedure, including Microsoft Graph API and PowerShell queries, see [the dedicated Microsoft 365 and Google Workspace OAuth audit guide](/blog/how-to-audit-oauth-app-grants-microsoft-365-entra-id-google-workspace).
Enumerate connected apps on every other sanctioned SaaS platform
Pull the connected-app or installed-integration list from each remaining platform's own admin console: Salesforce Setup > Connected Apps OAuth Usage, Slack's App Directory (Admin) showing installed apps and their granted scopes, GitHub Organization Settings > OAuth Apps and Installed GitHub Apps, and the equivalent screen in Snowflake, HubSpot, Workday, or any other platform holding sensitive business data. Each platform uses its own permission taxonomy and its own console layout; there is no shortcut around reviewing each one individually if you are not using an SSPM tool.
Deploy an SSPM tool for API-driven discovery at scale
If the estate exceeds a handful of platforms, a manual per-console review does not scale to a recurring cadence. An SSPM platform connects to each SaaS application's API once and continuously enumerates connected apps, granted scopes, and usage activity from that single connection, which is what makes a monthly or quarterly re-run of discovery practical rather than a multi-week manual project every time.
Cross-reference against identity provider SSO logs
Query your identity provider (Okta, Entra ID, or equivalent) for OAuth-based application authentications over the review period. Applications that authenticate through the identity provider but do not appear in a given platform's own connected-app list indicate either a gap in that platform's console coverage or an app connected through a path the console does not surface, both of which warrant investigation.
Step 2: Risk-Score Every Connected App
A discovery pass across a real SaaS estate will surface far more connected apps than can be individually investigated in one cycle. Score every app against consistent criteria so remediation effort goes to the highest-risk grants first, regardless of which platform they came from.
Scope breadth and sensitivity
An app holding read or write access to email content, file storage, CRM records, source code, or a data warehouse scores highest. Cross-platform equivalence matters here: Mail.ReadWrite in Microsoft Graph, https://mail.google.com/ in Google's OAuth scope model, and a Salesforce connected app with full data API access all represent the same underlying risk category even though the scope names look nothing alike.
Consent type: individual user versus organization-wide
A grant authorized by a single user for their own account is lower blast radius than a tenant-wide or organization-wide admin consent that applies the app's access to every user simultaneously. Weight organization-wide grants higher regardless of scope, because a compromise of that single grant compromises every user at once.
Publisher verification and app reputation
Apps without a verified publisher, apps with no public vendor security documentation, and apps whose registered developer account has no other verifiable footprint carry higher risk than apps from established, verified vendors. Treat unverified publisher status as a flag requiring manual confirmation of legitimacy, not an automatic block, since many legitimate internal or niche business tools never pursue formal publisher verification.
Last-used activity and grant age
An app with no sign-in or API activity in the last 90 days holds active permissions with no offsetting business justification currently in use. Age the grant against the employee who authorized it: a grant tied to an account that has since left the organization is a priority revocation candidate independent of the app's scope.
Chained and app-to-app connections
Some connected apps in turn connect to other apps or services, extending the effective blast radius beyond the direct grant. The Salesloft Drift breach reached Salesforce, Slack, and cloud storage environments through exactly this kind of chaining. Flag any connected app known to integrate outward to other platforms for a closer scope review, since its effective access may exceed what its direct scope list suggests.
Step 3: Establish a Recurring Review and Re-Certification Cadence
A single audit, however thorough, describes the estate at one point in time. New connected apps appear continuously as employees adopt new tools, and a program without a recurring cadence degrades back to its pre-audit state within months.
Set a re-certification interval by risk tier
Re-certify Priority 1 (organization-wide, high-scope) grants quarterly at minimum. Re-certify medium-risk individual-user grants at least every six months. Low-risk, narrow-scope grants from verified publishers can run on an annual cycle. Matching cadence to risk tier keeps the recurring workload proportionate instead of treating every grant identically.
Route re-certification through the app's actual business owner
Security cannot independently judge whether a marketing team still needs a given analytics integration. Send re-certification requests to the department or individual that originally authorized the app, requiring an affirmative confirmation that the app is still in active business use; treat non-response by a defined deadline as a revocation trigger, not an indefinite extension.
Alert on new high-privilege grants between cycles
A quarterly or semiannual cadence still leaves a window during which a high-risk grant sits unreviewed. Configure real-time or near-real-time alerting on new admin-consented or organization-wide grants above the medium-risk threshold, either through an SSPM tool's built-in alerting or a SIEM detection against each platform's audit log, so the highest-risk category of grant gets reviewed within days rather than waiting for the next scheduled cycle.
Track program metrics over time
Record the total connected-app count, the count of apps re-certified on schedule versus lapsed, and the count of grants revoked per cycle. A rising total app count with a falling re-certification completion rate is an early signal that the program is losing ground against new adoption, before it shows up as an incident.
Step 4: Revoke Access and Track Remediation
Revocation removes the connected app's active token or authorization. The mechanism differs by platform, and confirming the revocation actually took effect is a separate step from initiating it.
Revoke through the platform's native console or API first
Use each platform's own revocation path: Entra ID Enterprise Applications permissions revocation or the Microsoft Graph oauth2PermissionGrants delete endpoint, Google Workspace Admin SDK Tokens API token deletion, Salesforce's Connected App OAuth token revocation under Setup, Slack's app uninstall from the Admin App Directory, and GitHub's OAuth app authorization revocation under organization security settings. Native revocation is authoritative; an SSPM tool's own revocation action, where available, typically calls the same underlying platform API.
Confirm token invalidation, not just grant removal
Removing a grant record does not always immediately invalidate an access token already issued and cached by the application; some platforms allow a short-lived access token to remain valid until natural expiry even after the underlying grant is revoked. Where the platform supports it, force session or token revocation explicitly rather than assuming grant removal is instantaneous.
Document the business impact check before revoking anything active
For any app showing recent usage activity, confirm with the business owner before revoking, since an unannounced revocation of an actively used integration breaks a workflow with no warning. Reserve silent, no-notice revocation for apps confirmed dormant with no recent activity and no owner response during re-certification.
Close the loop with a revocation log
Record what was revoked, when, by whom, and why, tied back to the risk-scoring criteria that triggered it. This log is the evidence a subsequent audit or an incident investigation needs to confirm a given app's access was actually removed and stayed removed, rather than being silently re-granted by a user re-authorizing the same app later.
Validating That the Inventory Is Actually Complete
A connected-app inventory that looks thorough because it lists hundreds of apps is not the same as a complete inventory. Validate coverage with checks independent of the discovery method that built the list.
Cross-check discovery methods against each other
If using an SSPM tool for API-driven discovery, independently pull a sample platform's native connected-app list by hand and compare counts. A significant gap indicates either an API permission scope the SSPM tool lacks for that platform or a category of connection (personal OAuth apps, service accounts) the automated method does not capture.
Audit network and DNS telemetry for platforms not yet in the inventory
Cloud access security broker (CASB) log-based discovery, or a review of egress proxy and DNS logs for SaaS domains, surfaces platform usage independent of any admin-console-based method, which is the only way to find a SaaS platform your inventory does not know exists yet. A [shadow IT discovery program](/blog/shadow-it-discovery-management-enterprise) run alongside the connected-app audit closes this gap; connected-app discovery cannot find apps on a platform nobody has identified as in use.
Sample interview a cross-section of departments
Ask a handful of teams outside IT and security, particularly sales, marketing, and finance, to list the third-party tools they connect to core business systems. Compare their answers against the automated inventory. A tool an employee names that does not appear in the inventory is a concrete, actionable gap rather than a theoretical one.
Confirm coverage of every legal entity and tenant, not just the primary one
Organizations with subsidiaries, recently acquired companies, or regional business units frequently run separate SaaS tenants or entirely separate platform subscriptions that a corporate-level audit scoped to the primary tenant never touches. Confirm the inventory's scope explicitly includes or explicitly excludes each subsidiary tenant, rather than leaving the boundary undefined.
Failure Cases: Where Connected-App Audits Break Down in Practice
Even a well-run program has structural blind spots. Naming them explicitly is more useful than assuming the program eliminates the risk entirely.
Apps connected through personal accounts, not the corporate identity
An employee who connects a corporate Google Drive or Slack account to a third-party tool using a personal email-based OAuth flow, or who exports data to a personal account first and connects apps there, creates access entirely outside the corporate tenant's visibility. No amount of admin-console review of the corporate tenant surfaces this, because the grant does not exist inside it. This gap is a training and data loss prevention (DLP) problem, not a console-configuration problem, and no connected-app audit closes it on its own.
Subsidiaries and related tenants outside the audit's declared scope
As noted in validation, a merger, acquisition, or loosely governed regional business unit can run SaaS platforms and tenants the primary audit never enumerates. Absent an explicit organizational mapping exercise identifying every legal entity and its associated SaaS tenants, these stay invisible indefinitely, not just until the next audit cycle.
Non-OAuth access paths: API keys, service accounts, and personal access tokens
OAuth is one authorization mechanism among several. Static API keys, platform-specific service accounts, and developer personal access tokens (GitHub PATs, for example) grant comparable standing access without going through an OAuth consent flow at all, and an audit scoped strictly to OAuth grants will not enumerate them. A complete program tracks these credential types alongside OAuth grants, not as a separate, deprioritized effort.
Browser extensions with SaaS platform permissions
Browser extensions that request access to a SaaS platform's web session, rather than going through the platform's OAuth flow, can read or manipulate data inside apps like Google Workspace or Salesforce without ever appearing in that platform's connected-app list. This access path requires browser-extension inventory and management as a distinct control, layered alongside the SaaS-platform-level connected-app audit.
Security Tradeoffs: Consent Friction Versus Risk Reduction
Tightening OAuth consent policy and adding a re-certification requirement reduces standing risk, but it is not a free change. Weigh the tradeoff explicitly rather than defaulting to the strictest available setting.
Blocking all user consent shifts the request to IT, not away entirely
Setting a platform's consent policy to require admin approval for every third-party app does not eliminate the underlying business need for those tools; it routes the request through an approval queue. If that queue is slow or understaffed, employees under deadline pressure look for workarounds, including the personal-account shadow IT path described above, which is strictly worse for visibility than the user-consent grant it was meant to prevent.
A recurring re-certification requirement creates real ongoing workload for business teams
Asking department owners to reconfirm every connected app on a quarterly or semiannual basis is a genuine time cost multiplied across every team and every app. Setting the cadence too aggressively for the organization's actual risk tolerance produces rubber-stamp responses that defeat the purpose of the review, rather than more careful ones.
Overly aggressive dormant-app revocation risks breaking infrequent but legitimate workflows
Some legitimate business processes run quarterly, annually, or on an irregular schedule tied to external events (year-end reporting tools, audit-season integrations), and a 90-day inactivity threshold will flag them as dormant even though they are still needed. Build an exception path for confirmed low-frequency, high-legitimacy use cases rather than applying the inactivity threshold uniformly.
The net direction is still toward tighter governance, calibrated to the organization
None of these tradeoffs argue against building the program; they argue for calibrating consent policy strictness, re-certification cadence, and revocation thresholds to the organization's actual risk profile and operational tolerance, and revisiting that calibration as the program matures rather than setting it once and leaving it fixed.
The bottom line
OAuth token sprawl is not solved by a single audit, no matter how thorough, because new connected apps enter the SaaS estate continuously and most of the platforms holding sensitive data outside Microsoft 365 and Google Workspace have no equivalent of a mature admin consent console. Building a recurring program, discovery across the full platform inventory, consistent cross-platform risk scoring, a re-certification cadence matched to risk tier, and a revocation process with a documented audit trail, converts token sprawl from an accumulating unknown into a managed and periodically re-verified population. Pair it with the platform-specific enumeration detail in the Microsoft 365 and Google Workspace audit guide, and treat the failure cases (personal-account shadow IT, unmapped subsidiary tenants, non-OAuth credentials, and browser extensions) as permanent residual risk to monitor for rather than gaps a future audit will eventually close.
Frequently asked questions
What is the difference between OAuth token sprawl and a single OAuth consent phishing incident?
OAuth consent phishing is a single attack where a victim is tricked into authorizing a malicious app in one incident. Token sprawl is the ongoing, cumulative buildup of many legitimate and illegitimate connected apps across an entire SaaS estate over months and years, most never reviewed, which creates the standing attack surface that a phishing attack, an insider, or a compromised vendor can exploit.
How is a SaaS-wide connected app audit different from a Microsoft 365 and Google Workspace OAuth audit?
A Microsoft 365 and Google Workspace audit covers the two platforms with the most mature native admin consoles for OAuth grants. A SaaS-wide audit extends the same discipline to every other platform holding sensitive data, such as Salesforce, Slack, GitHub, and Snowflake, each with its own separate connected-app population and its own console, which a two-platform audit never touches.
How often should an organization re-certify OAuth connected app grants?
Re-certify the highest-risk grants, organization-wide admin consent with broad scope, at least quarterly. Medium-risk individual user grants can run on a six-month cycle, and low-risk grants from verified publishers with narrow scope can run annually, with real-time alerting layered on top for any new high-privilege grant between cycles.
Can an SSPM tool fully replace a manual OAuth grant audit?
An SSPM tool such as AppOmni, Obsidian Security, or Nudge Security automates discovery and risk scoring across many platforms from a small number of API connections, which is the only practical way to sustain a recurring program at scale, but it should be validated against independent methods like network telemetry and department interviews rather than trusted as the sole source of truth.
Why do connected app audits miss apps connected through personal accounts?
An employee who connects a personal email account or a personal cloud storage account to a third-party app, rather than their corporate identity, creates an OAuth grant entirely outside the corporate tenant that no admin console can see, since the grant was never issued inside the tenant being audited in the first place.
What should happen when a connected app audit finds a high-risk grant nobody remembers authorizing?
Treat it as a potential compromise indicator rather than routine cleanup: check the platform's consent or authorization audit log for the granting user and timestamp, contact that user to confirm whether they recognize the authorization, and revoke the grant immediately if it cannot be confirmed as a legitimate, intentional business authorization.
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.