OAuth token theft is one of the most common modern IAM failure modes because it bypasses controls people assume 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 an enterprise‑neutral, practical checklist you can apply to any SaaS or API ecosystem.
1) 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 application (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.
2) Why this matters: bearer tokens bypass MFA by design
MFA happens during authentication. OAuth access tokens are typically issued after authentication. If a token is stolen, the attacker uses it as a bearer credential (“possession = access”).
That’s not a bug. It’s the defining property of bearer tokens.
A useful enterprise mental model:
- Password + MFA protects the login ceremony.
- Tokens are the runtime credential used for API calls and sessions.
- If the runtime credential is stolen, the attacker can often operate without re‑authenticating.
This is why “we enforce MFA everywhere” is necessary—but not sufficient—when your environment depends on SaaS‑to‑SaaS integrations and API ecosystems.
3) Where tokens get stolen in the real world
Token loss usually comes from operational reality, not theoretical protocol flaws:
- Browser/session compromise (session cookies, SPA tokens in storage)
- Endpoint compromise (tokens cached by CLIs/SDKs)
- CI/CD exposure (tokens printed to logs, copied into artifacts, reused across jobs)
- Over‑scoped third‑party apps (OAuth grants behaving like privileged integrations)
- Refresh token theft (persistence even after you “kick out” a session)
Two high‑value takeaways:
- Tokens move. They get copied between systems, pipelines, browser profiles, and tooling.
- Tokens persist. Especially refresh tokens and client credentials.
4) The ecosystem is the attack surface
The uncomfortable reality:
- You can harden Salesforce (or any SaaS) correctly.
- And still get compromised through a connected app with broad scopes.
Treat connected apps like privileged integrations:
- require an owner and business justification
- review scopes like permissions (least privilege)
- standardize onboarding (what’s allowed, what’s not)
- ensure revocation is fast and tested
In practice, your biggest risk is usually the top 10 connected apps by scope breadth and usage.
5) Controls that reduce replay and persistence (what actually works)
5.1 Shorten access token lifetimes (where possible)
Short lifetimes reduce the window where theft is useful.
| Token | Typical “default” | Better target |
|---|---|---|
| Access token | 1–12 hours (or more) | 5–60 minutes for high‑risk APIs |
| Refresh token | weeks/months | rotation + reuse detection |
If you can’t reduce access token lifetimes due to legacy clients, compensate with:
- anomaly detection and conditional access (IP/device posture)
- step‑up for sensitive actions
- rapid revocation and session invalidation (next sections)
5.2 Treat refresh tokens and client credentials as high‑value secrets
If an attacker gets a refresh token (or long‑lived client credential), they can persist.
Google’s guidance emphasizes this “persistence” problem: even after you clean an endpoint, copied tokens can still be used elsewhere.
Source: https://cloud.google.com/architecture/bps-for-mitigating-gcloud-oauth-tokens
Practical hardening checklist:
- refresh token rotation
- reuse detection / “token replay” alerts
- avoid long‑lived offline access unless required
- store client secrets in a real secrets system (Vault/Secrets Manager/Key Vault)
5.3 Reduce token replay risk with sender‑constrained tokens (when you control the APIs)
Bearer tokens are replayable by design. If your stack supports it, sender‑constrain tokens so a stolen token is less useful:
- mTLS-bound tokens
- DPoP (proof‑of‑possession)
These aren’t always available in SaaS products, but for your own APIs and modern gateways they’re worth considering.
Learn IAM topic: https://learn-iam.com/topic/specifications/dpop-and-sender-constrained-tokens
5.4 Govern connected apps like privileged access
You need to know:
- which apps are connected
- what scopes they have
- who approved them
- which users/tenants granted them
- how to revoke them quickly
Enterprise patterns that work:
- block user-consent for high‑risk scopes; require admin approval
- require publisher verification / allowlisting where supported
- quarterly review of the top apps (by scope breadth, number of grants, or data access)
5.5 Build a token-theft revocation playbook (and practice it)
Token theft response should be as muscle‑memory as password resets.
At minimum, your playbook should cover:
- Identify what was stolen
- access token vs refresh token vs session cookie vs client secret
- Revoke at the right layer
- revoke refresh tokens / sessions
- disable/remove the connected app (or reduce scopes)
- rotate client secrets / signing keys (if applicable)
- Contain blast radius
- temporarily restrict sensitive scopes
- restrict API access by IP/device posture (if supported)
- Hunt
- look for suspicious API patterns (exports, admin actions, new grants)
- Recover
- remove persistence paths (re-issue clean tokens, re-approve apps, rotate downstream secrets)
Reality check: “logout” may not revoke already-issued bearer tokens. You need explicit revocation and/or short lifetimes.
6) Salesforce-specific checklist (applies to most SaaS ecosystems)
If your incident involves Salesforce (or similar SaaS), prioritize:
- inventory of connected apps + scopes
- unusual API activity (bulk exports, metadata reads, admin operations)
- new OAuth grants or unusual grant patterns
- tokens issued to third‑party apps with broad permissions
Operationally, the goal is to answer:
- which integration principal had access
- which data objects were accessed
- whether refresh tokens enabled persistence
- how quickly you can disable the integration without breaking critical business workflows
7) What Learn IAM covers next
Deep dive topic:
If you’re building tool‑using AI systems, token security becomes even more important because tool calls are token-backed API calls: