Every AI tool, workflow automation, and productivity app your employees connected to Google or Microsoft this year left behind a persistent OAuth token. These tokens have no expiration date, no automatic cleanup, and in most organizations, no monitoring. Your perimeter controls don't see them. Your MFA doesn't stop them. And when an attacker obtains one, they don't need a password.
New research from Material Security reveals the gap between awareness and action: 80% of security leaders consider unmanaged OAuth grants a critical or significant risk, yet 45% of organizations do nothing to monitor OAuth grants at scale. Another 33% rely on manual processes—spreadsheets, ad hoc reviews, and employee reporting. Spreadsheets aren't a threat response capability. They're documentation of unknown exposure.
OAuth Tokens: The Persistent Access Grant Nobody's Watching
OAuth grants don't expire when employees leave. They don't reset when passwords change. They persist indefinitely unless explicitly revoked. The model made sense when a handful of IT-approved apps needed calendar access. It breaks down when every employee independently connects AI tools, workflow automations, and productivity apps directly into their Google or Microsoft environment—each receiving a persistent, scoped token with no automatic expiration and no centralized visibility.
This isn't a misconfiguration. It's how OAuth is designed to work. The problem is that most security programs weren't built to account for it at scale. The tokens are legitimate. The integrations are legitimate. From the perspective of perimeter controls, nothing appears wrong.
The Drift Attack: 700+ Organizations Compromised Through Legitimate OAuth Tokens
Drift, a sales engagement platform acquired by Salesloft, maintained OAuth integrations with Salesforce instances across hundreds of customer organizations. Threat actor UNC6395 obtained valid OAuth refresh tokens—likely through prior phishing campaigns—and used them to access Salesforce environments belonging to more than 700 organizations.
The attack structure is instructive: the tokens were legitimate, the integration was legitimate, and MFA was bypassed entirely because the attacker wasn't logging in. They were presenting a token that Drift had already been granted permission to use. Once inside, UNC6395 systematically exported data and extracted credentials: AWS access keys, Snowflake tokens, passwords. Cloudflare, PagerDuty, and dozens of other organizations were affected. The full scope is still being assessed.
The Drift incident wasn't an attack from a suspicious, unknown app. It was an attack through a trusted one. The lesson: trusting an app at installation doesn't mean it stays trustworthy. OAuth grants require active, continuous monitoring rather than passive acceptance.
Why Current OAuth Security Tools Miss the Real Threat
The current generation of OAuth security tools addresses risk at the point of installation. They check whether a requested permission scope is excessive. They may flag apps from vendors with poor reputations. That's useful—but insufficient.
For the Drift scenario—a legitimate app whose credentials were later stolen and weaponized—point-in-time evaluation catches nothing. A tool that only evaluates the grant at creation would have seen nothing wrong. The risk materialized later, when the token was stolen and used by a different actor entirely.
Vendor trust levels and app scopes only tell part of the story. Monitoring the actual behavior of the app—the API calls it makes, the actions it takes—is critical to understanding what the app is actually doing, not just what it could do. Without deep visibility into the account(s) the app is linked to, you're operating half-blind. A risky app tied to an intern's account is one thing. The same app used by a VIP with access to sensitive emails, files, and systems is categorically different.
What Effective OAuth Monitoring Requires
Effective OAuth security requires three core capabilities that most organizations lack:
- Continuous behavioral monitoring, not point-in-time review. Monitor API calls an OAuth-connected app makes over time to reveal anomalies no static permission review can catch—sudden spikes in data access, queries for unusual data types, access at unexpected hours.
- Blast radius assessment. An OAuth grant connected to an account with read access to thousands of sensitive documents and years of email history is categorically different from the same grant on a freshly provisioned account. The reach of the user's account determines the potential impact of a compromised or malicious OAuth connection.
- Graduated response matched to organizational risk tolerance. An obviously malicious app—unknown vendor, broad permissions, anomalous API behavior—shouldn't sit in the environment while a ticket works through a queue. It should be revoked immediately. A mission-critical integration from a major vendor showing mild anomalies warrants human review before action.
Organizations don't need perfect OAuth visibility on day one. They need to move from no monitoring or manual spreadsheets to automated, continuous visibility that can detect anomalous behavior and assess blast radius. The gap between current practice and effective security is measurable—and closable.
The Gap Between Awareness and Capability
CISOs have known OAuth grants represent a risk for years. The Material Security research quantifies why awareness hasn't translated to action: the security tools available don't match the problem. Point-in-time app vetting doesn't address post-installation compromise. Manual spreadsheet tracking doesn't scale. And without behavioral monitoring tied to blast radius assessment, security teams can't distinguish between acceptable business use and active exploitation.
The Drift attack demonstrates that OAuth tokens are not theoretical risk. They're an active attack vector that bypasses MFA, persists after credential resets, and operates within the bounds of legitimate-looking activity. Organizations that continue treating OAuth monitoring as a future priority rather than a current gap are operating with a backdoor their attackers already know about.
What Security Teams Should Do Now
Start by establishing visibility. Inventory OAuth grants across Google Workspace and Microsoft 365 environments. Identify which apps have access to what scopes, which user accounts they're connected to, and what data those accounts can reach. Move from manual tracking to automated monitoring that can flag anomalous API behavior in real time.
Prioritize high-blast-radius accounts. OAuth grants connected to executive accounts, IT administrators, or users with broad data access represent disproportionate risk. These should be monitored more closely and reviewed more frequently than grants on limited-access accounts.
Establish automated response workflows. Define clear criteria for immediate revocation versus human review. An unknown app making unexpected API calls at 3 AM shouldn't wait for a weekly review meeting. A known enterprise app showing moderate anomalies should trigger investigation, not automatic action.
The OAuth backdoor exists by design. The question is whether your security program accounts for it at scale, or whether you're the 45% doing nothing while attackers already know the way in.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us