# The OAuth Graveyard Living Inside Your Google Workspace
Every fast-growing company has them: a dozen forgotten integrations collecting dust in their Google Workspace environment, authorized by someone who left three jobs ago, connected to a vendor that pivoted or got acquired, carrying permissions that were probably excessive when they were granted and are now a standing invitation to anyone who can compromise the other end.
This is the OAuth graveyard problem, and it doesn't get nearly enough attention relative to how reliably it enables breaches.
## The Invisible Attack Surface
When a company adopts Google Workspace, they're really adopting an ecosystem. Slack connects. Salesforce connects. So does the scheduling tool the marketing team tried for six weeks in 2022, the invoice automation platform that got replaced, and whatever the engineering team wired up to test a webhook. Each of those integrations goes through an OAuth authorization flow that feels routine — click, approve, done — and then it lives there, indefinitely, unless someone actively revokes it.
The problem isn't just that people forget about these integrations. It's that the permissions granted during setup tend to be broad. Developers, particularly at early-stage companies, often approve the widest scopes the vendor requests because it's easier than debugging scope-related failures later. So that forgotten calendar tool? It may have read access to every calendar in the domain. That old document signing integration? It might still have permission to read and write files across the entire Drive.
Google's admin console does expose third-party app access — but the interface isn't exactly designed to make auditing intuitive. Admins have to know where to look, and at companies scaling fast, this kind of hygiene competes with a hundred other priorities.
## How Attackers Actually Use This
The attack chain isn't complicated, which is part of why it works.
An attacker compromises a small SaaS vendor — through phishing, a credential stuffing campaign, or a software supply chain incident. That vendor has OAuth tokens connecting them to hundreds or thousands of enterprise customers. The attacker uses those tokens to pivot into those environments, bypassing MFA entirely because OAuth tokens are pre-authenticated. They're not logging in as the user; they're acting as the application.
This is exactly what happened in the Twilio breach in 2022. Attackers who compromised Twilio employees found they could reach downstream customers through legitimate service integrations. The breach surface wasn't just Twilio — it was everyone connected to Twilio in ways that hadn't been carefully scoped or audited. Okta's breach the same year followed a similar pattern: compromise a vendor, inherit their access.
The through-line is consistent. The weakest link isn't the enterprise's perimeter — it's the smallest vendor in their integration graph who happens to hold a token with domain-wide access.
## The Fast-Growth Trap
The title of the webinar that prompted this piece specifically mentions "fast-growing companies," which is accurate targeting. The problem scales inversely to process maturity.
An enterprise with a formal procurement process and a vendor risk program reviews integrations during onboarding and periodically thereafter. They have someone whose job description includes asking "who has access to our Google Workspace and why?" Fast-growing companies — the Series A startup that just doubled headcount, the mid-market SaaS company that's been in hypergrowth for three years — typically don't. The person who authorized those integrations is either still there and thinks someone else is tracking it, or they left and took that context with them.
There's also a cultural dynamic worth naming: at growth-stage companies, security friction is often treated as a product velocity problem. The developer who wants to wire up a new tool doesn't want to file a ticket and wait two weeks. The shortcut is to use whatever broad permissions get the thing working. The integration accumulates. Nobody reviews it. Two years later, that vendor gets breached.
## What Controls Actually Help
Auditing third-party app access in Google Workspace requires visiting the Admin Console under Security > API Controls > App access control. Most admins who've never done this will be surprised by what they find.
The practical controls worth implementing:
Restrict which apps can be authorized at all. Google Workspace allows admins to block access from unconfigured third-party apps by default, requiring explicit approval before a new integration can be granted access. This single control cuts off most of the "someone installed something and forgot" vector.
Run a scope audit, not just an app audit. The question isn't just "what apps have access" — it's "what can those apps actually do." An app with read-only access to a single calendar is a different risk profile than one with domain-wide delegation. Triage by scope, not just by volume.
Set access review on a calendar. Quarterly is reasonable for most companies. The goal is to make revocation a routine operation rather than a crisis response. Apps that haven't been used in 90 days should have their access revoked by default unless someone actively recertifies them.
Treat OAuth tokens as credentials. They are credentials. They should appear in your secrets management inventory, have an owner, and have a review date. The fact that they look like a checkbox in a UI doesn't make them lower risk than an API key.
---
## HackWire Analysis
The framing of this problem as a "forgotten access" issue is technically accurate but undersells the systemic nature of it. OAuth sprawl isn't a housekeeping failure — it's an architectural consequence of how the SaaS ecosystem was designed.
OAuth was built for user convenience: grant access once, don't deal with credentials again. The problem is that "once" turned out to mean "forever unless explicitly revoked," and the revocation workflow was bolted on as an afterthought in most admin interfaces. Google's isn't terrible, but it's also not a system designed to surface risk proactively. You have to go looking for it.
What's missing from most coverage of this problem is the supply chain dimension. Security teams at large companies have gotten reasonably good at reviewing direct vendor relationships — the big CRM, the HRIS system, the cloud infrastructure provider. They have questionnaires and review cycles. What they rarely review is the access chain: who does that vendor connect to, and who does *that* party connect to? A single OAuth token held by a four-person startup that does document automation can be a valid key to a Fortune 500's Google Drive if the right admin authorized it three years ago.
The 2024 threat landscape makes this more urgent, not less. Threat actors — particularly groups with ransomware or data extortion motives — have shifted heavily toward credential-based initial access precisely because perimeter defenses have improved. OAuth tokens are credentials. They bypass MFA. They're valid for as long as the integration exists. And in most organizations, nobody is watching them.
The fix isn't complicated, but it requires treating this as a real security control rather than an admin task. If your organization hasn't done an OAuth audit in the last six months, that's where this analysis should end up — in a ticket, not a reading queue.
— HackWire Editorial
---
## Related Coverage