OAuth Token Theft Is the New Phishing: SaaS-to-SaaS Attack Audits

Cybersecurity

Stolen OAuth tokens give attackers persistent access without ever phishing a password. The attack class has been growing every quarter. The audit we run on every customer's third-party app integrations.

By Arjun Raghavan, Security & Systems Lead, BIPI · April 15, 2026 · 8 min read

The attack pattern that reliably bypassed our clients' phishing-resistant MFA in 2025 was not a credential phish. It was an OAuth token theft. The attacker convinces a user to authorise a third-party app, the app gets tokens scoped to mailbox or document access, and the attacker has persistent access without ever seeing a password. MFA is irrelevant to the post-token flow.

Microsoft, Google, and Slack data all showed the same trend through 2025: malicious-app installs grew faster than every other initial-access vector. The audit below is what we run now on every cybersecurity engagement that touches a SaaS estate.

The attack pattern

The attacker registers a legitimate-looking app with the SaaS provider — Google Workspace, Microsoft 365, Slack, Salesforce. The app name resembles a benign productivity tool ('PDF Sign Pro', 'Calendar Helper'). The attacker sends a phishing email with a link that triggers the OAuth consent flow.

The user clicks. The legitimate provider page shows the consent prompt. The user grants the permissions. Tokens are issued to the attacker's app. From here, the attacker reads mail, accesses documents, sends mail-as-the-user, downloads contact lists. MFA does not re-prompt because OAuth grant counts as the authentication.

Why this beats traditional defences

Three reasons. First, the consent screen is hosted on the legitimate provider's domain. URL-based phishing detection fails because microsoft.com is genuinely the URL. Second, the user often has institutional habit of clicking through OAuth prompts because legitimate tools also use them. Third, the resulting tokens persist; revoking the user's password does not invalidate them.

The six-point audit

1. Inventory every app with OAuth grants in your Workspace or M365 tenant. Most admins have never looked. Typical org has 200 to 800 apps with delegated permissions, half of which were authorised by a single user one time and then forgotten.
2. Review high-permission apps. Apps with 'mailbox.read', 'files.readwrite.all', 'user.read.all' are the targets. Anything with these permissions that does not appear on a written approved-apps list is investigated.
3. Check publisher verification. Both Microsoft and Google offer publisher verification badges. Apps without verification are higher risk; apps with stale or missing publisher info are flagged.
4. Look at user-distribution patterns. An app authorised by exactly one user is suspicious. An app authorised by 50 users in finance is operationally normal. Single-user grants are where attacker-pretext apps land.
5. Review last-used timestamps. Apps that received tokens once and have not been used in 60 days are good candidates for revocation regardless of risk.
6. Check for impossible-travel patterns on token usage. A legitimate app called from the US during business hours is normal. The same app called from Russia at 3 AM uses the same tokens; the attacker is using them.

Preventive controls

Three controls reduce the attack surface materially.

Admin-only OAuth consent. Configure the tenant so users cannot grant OAuth consent themselves; consent must be approved by an admin. Microsoft calls this 'app consent policies'; Google calls it 'app access control'. The cost is friction (admins approve apps); the benefit is removing the attack vector entirely.

Pre-approved app lists. The admin maintains a list of apps that users may install without further review. Anything not on the list goes through admin approval. The list grows organically; the unknown apps are blocked.

Token-binding policies. Conditional Access (Microsoft) or Context-Aware Access (Google) can require that OAuth tokens be bound to managed devices. Tokens stolen from a managed device cannot be replayed from an attacker's machine because the device-binding fails.

Detection

Two SOC rules close most of the gap. Alert on any new OAuth consent grant for an app with high-permission scopes. Alert on any token usage from an IP outside the user's normal geo. The first catches the install; the second catches the abuse.

Closing

OAuth token theft is the SaaS-era replacement for credential phishing. It bypasses MFA by design because OAuth was designed to be the authentication. The defence shifts up the stack: control which apps can request tokens, monitor which tokens are used from where, and treat the OAuth grant log as the same kind of asset as the auth log itself.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.