OAuth token theft is one of the most common “modern IAM” failure modes because it bypasses the controls people think they’re relying on.
If an attacker steals a valid token, they often don’t need:
- the user’s password
- MFA
- the ability to phish a new login
They just need the token.
This post uses the Salesforce/Drift incident as a concrete example and turns it into a practical checklist you can apply to any SaaS or API ecosystem.
What happened (the short version)
Google’s Threat Intelligence Group described a campaign where attackers used stolen OAuth tokens issued to a trusted third‑party app (Salesloft Drift) to access Salesforce instances.
Key point: this wasn’t a “Salesforce login got bypassed” story. It was a “the integration already had permission and the token became the credential” story.
Why this matters: tokens bypass MFA by design
MFA happens during authentication. OAuth tokens are issued after authentication. If a token is stolen, the attacker uses it as a bearer credential.
That’s not a bug. It’s the core property of bearer tokens.
The ecosystem is the attack surface
The uncomfortable takeaway:
- You can harden Salesforce (or any SaaS) perfectly.
- And still get owned through one connected app with broad scopes.
You have to treat every connected app like a privileged integration.
Practical mitigations (token security in the real world)
1) Make access tokens short-lived
Short lifetimes reduce the window where theft is useful.
2) Treat refresh tokens like high-value secrets
If an attacker gets a refresh token (or a long-lived client credential), they can persist.
Google’s guidance for compromised OAuth tokens emphasizes this “persistence” problem: even after you kick an attacker off a machine, copied tokens can still be used elsewhere.
Source: https://cloud.google.com/architecture/bps-for-mitigating-gcloud-oauth-tokens
3) Inventory + govern connected apps
You need to know:
- which apps are connected
- what scopes they have
- who approved them
- how to revoke them quickly
4) Build a revocation playbook
Token theft response should be as muscle-memory as password resets:
- revoke refresh tokens / sessions
- remove or disable the connected app
- rotate downstream credentials found in SaaS records
- hunt logs for suspicious API queries
What Learn IAM covers next
If you want the deeper version, this is now a full topic:
And if you’re building an “agentic” system, MCP makes this even more important because tool calls are effectively token-backed API calls: