The Secret Backdoor in Your SaaS: How Persistent OAuth Tokens Turn “Shadow Apps” into an Attacker’s Golden Ticket

What if the most dangerous backdoor into your business isn’t in your firewall or VPN—but in the “Allow” button employees click every day?

In the race to automate work and connect AI tools with Google Workspace or Microsoft 365, most organizations have quietly created a parallel identity ecosystem: thousands of OAuth grants and tokens—many persistent, rarely monitored, and often never expiring. Attackers know this. Most security teams don’t. That gap is being exploited at massive scale.

A recent incident covered by The Hacker News makes this painfully clear. Threat actor UNC6395, tracked by Palo Alto Networks Unit 42, obtained valid OAuth refresh tokens—likely via prior phishing—and used them to access Salesforce environments across more than 700 organizations. The path in? OAuth integrations between customers’ Salesforce instances and Drift (acquired by Salesloft), a widely used sales engagement platform.

If “OAuth token” sounds abstract, think of it this way: a refresh token is a reusable backstage pass. It isn’t a password. It isn’t protected by MFA prompts. It quietly works in the background to mint new access tokens over and over, sometimes for months or years, until someone explicitly revokes it. That’s a dream for automation—and a dream for attackers.

In this post, we’ll break down how this backdoor works, why it’s rarely visible to defenders, and exactly how to close it without breaking the business.

TL;DR (but please don’t): OAuth tokens are an unmonitored identity perimeter

OAuth refresh tokens tied to employee-connected apps can bypass passwords, MFA, and traditional network controls.
Many of these tokens don’t expire quickly—or at all—and persist until manually revoked.
Attackers phish, intercept, or steal these tokens to gain long-lived, low-noise access to core systems like Salesforce, Google, and Microsoft 365.
The Drift/UNC6395 incident shows this is not hypothetical—it’s a live, industrial-scale attack path.
The fix: get visibility into OAuth grants, enforce expiration and governance, monitor anomalous app access, and bake token hygiene into IAM.

Let’s unpack what’s going on and what you can do this quarter.

How OAuth became the enterprise’s most ignored attack surface

OAuth 101: Why we love it—and why attackers love it more

OAuth 2.0 is the standard that lets you click “Sign in with Google/Microsoft” and authorize third-party apps to access your data without sharing your password. It’s beautifully convenient and massively adopted. The official specs live at RFC 6749 and token revocation at RFC 7009; PKCE for safer code flows is RFC 7636.

Access token: Short-lived bearer token that grants access to a resource (e.g., read your Calendar).
Refresh token: Longer-lived token used to obtain new access tokens without user interaction—often includes the “offline_access” scope.
Grant/consent: The durable relationship that lets an app act on behalf of a user or organization.

In practice: – Access tokens are like temporary door badges.
– Refresh tokens are like a master key the app keeps in a drawer.
– The consent/grant is like a standing contract to honor the key indefinitely—unless revoked.

The quiet spread of “shadow” OAuth

Employees have connected thousands of tools—AI assistants, sales automations, low-code workflows, note-takers, schedulers—to core identities. This spans: – Google Workspace: Gmail, Drive, Calendar, Docs
– Microsoft 365/Entra ID: Outlook, OneDrive, SharePoint, Teams, Graph API
– Salesforce and its Connected Apps ecosystem
– HRIS, CRM, marketing automation, and finance SaaS

Every integration may create one or more tokens, stored outside your identity provider, often with broad scopes. These tokens are a new perimeter—but they rarely show up in your SIEM dashboards or IAM risk reviews.

Why traditional controls miss this

MFA doesn’t apply: After initial consent, refresh tokens mint new access without more prompts.
Zero Trust network controls don’t help: OAuth is cloud-to-cloud; traffic may never touch your network.
Password rotations don’t matter: Tokens outlive password changes.
Endpoint agents don’t see it: Tokens sit in vendor clouds or browser storage, not your endpoints.
Logging is fragmented: Audit trails live across resource providers, consent stores, and app vendors.

MITRE ATT&CK classifies this pattern under “Use of Alternate Authentication Material” (T1550). In other words: it’s credential abuse, just not the kind your playbooks are tuned to catch.

The Drift/UNC6395 case: What it teaches us

According to The Hacker News report, UNC6395 obtained valid OAuth refresh tokens and used Drift’s Salesforce integrations to access customer Salesforce data across hundreds of organizations—reportedly over 700. The suspected initial access? Prior phishing that harvested credentials or sessions enabling token capture, followed by abuse of existing OAuth grants.

Key takeaways: – OAuth grants are not passive risk. They’re an active intrusion vector.
– A single vendor’s integration can fan out into hundreds of target environments.
– Once attackers get refresh tokens, they can operate for a very long time with low noise.
– Customers typically lack centralized visibility into third-party apps’ token stores or refresh behavior.

This is not a Salesforce issue per se, nor a Google/Microsoft flaw. It’s a systemic identity governance gap across SaaS ecosystems.

For context on Salesforce app models, see Salesforce’s own docs on Connected Apps. For broader threat research and trends in token abuse, monitor Unit 42.

Where the tokens hide (and why they’re hard to kill)

In third-party vendors’ clouds: The app you authorized stores refresh tokens inside its backend.
In your IdP’s consent store: Microsoft Entra ID and Google track which apps have access and which users granted it.
In browsers and local caches: Some desktop/web apps cache tokens locally.
In automation platforms: No-code tools and bots regularly hold organization-wide tokens.

Killing a token isn’t one action. You often need to: 1) Revoke at the issuing IdP (Google/Entra/Salesforce).
2) Ensure the resource provider honors revocation.
3) Invalidate the app’s cached tokens and secrets.
4) Audit and remove the underlying grant/consent.

If any step is missed, access can persist.

Why this matters more now

AI copilots and automation tools are multiplying OAuth connections exponentially.
“Offline” access scopes are common—allowing background processing without users present.
Vendors differ widely in token lifetime, rotation, and revocation hygiene.
Attackers have adapted: token theft is lower-friction than password theft and far stealthier than malware.

The real risk isn’t Shadow IT—it’s Shadow Identity

Security leaders often focus on stopping employees from installing unapproved apps. That’s necessary but not sufficient. The deeper issue is that tokens extend your identity perimeter into every connected SaaS, where your controls and telemetry are weakest.

Identity is the new perimeter only if you can see all of it.

Immediate actions: What to do in the next 30 days

You can reduce your risk materially this quarter without freezing the business. Prioritize these steps:

1) Get visibility into OAuth grants and high-risk apps

Microsoft 365/Entra ID:
Review Enterprise Applications and OAuth consents under App Registrations and Enterprise Apps.
Enable and use Microsoft’s App governance capabilities (part of Defender for Cloud Apps) to discover risky OAuth apps.
Tighten consent policies via the Microsoft consent framework.
Google Workspace:
Enforce domain-wide OAuth app access controls.
Only trust verified apps; block or restrict unverified/scoped apps.
Salesforce:
Inventory Connected Apps and their OAuth scopes.
Audit which integrations have “Perform requests on your behalf at any time (refresh token, offline access).”
Cross-SaaS:
Pull audit reports of OAuth consents, token issuance, and app usage across your top 10 critical SaaS platforms.
Tag apps with high-sensitivity scopes (mail.read, files.readwrite, contacts.readwrite, full_access, offline_access).

2) Revoke and reduce

Remove unused or low-value app grants, starting with those holding offline/refresh scopes.
For vendors no longer in contract, revoke all org- and user-level OAuth grants.
Require re-consent for critical apps with tightened scopes and least privilege.

3) Force shorter token lifetimes and require proof of revocation

Where configurable, reduce refresh token lifetimes and disallow perpetual refresh.
Ask vendors to confirm support for RFC 7009 token revocation and publish revocation endpoints and SLAs.
Disable “remember me” and persistent sessions for admin roles.

4) Turn on anomaly detection specifically for OAuth activity

Alert on:
New high-privilege app consents by non-admins.
Sudden spike in token minting for a single app or user.
App activity from unusual geographies or IP ranges.
API access at odd hours for users who normally don’t use those APIs.
In Microsoft, enable Continuous Access Evaluation (CAE) to react faster to risk changes.
Ensure OAuth-related logs are ingested into your SIEM.

5) Prep an “OAuth incident” runbook

Include steps to: identify grants, revoke across IdP/resource/app, rotate secrets, validate vendor revocation, and notify data owners.
Simulate a token-theft scenario quarterly.
Coordinate with Legal and Privacy for potential third-party data exposure.

Medium-term program: Build OAuth governance into your IAM

Set policy with business buy-in

Default-deny third-party app consent except for vetted marketplaces and verified publishers.
Require security review for apps requesting offline_access or broad data scopes.
Establish data classifications and map scopes to those classes.

Centralize approvals and automate reviews

Use a single intake process for app requests, routing to Security + IT + Data Owners.
Auto-expire app consents every 90–180 days unless re-justified.
Quarterly review of all OAuth grants for critical SaaS; remove dormant ones.

Instrument your stack

Microsoft:
Conditional Access for app consent and risky sign-ins.
Defender for Cloud Apps “App governance” alerts and policies.
Audit Graph API usage and set alerts for privilege escalation via app roles.
Google:
Enforce “Trust internal, restrict external” policies for high-risk scopes.
Monitor Admin audit logs for OAuth grant events and token issuance surges.
Salesforce:
Require IP restrictions and session policies on Connected Apps.
Turn on high-risk event monitoring for API access anomalies.
Cross-reference with your EDR/XDR to correlate unusual endpoint activity with OAuth events.

Bake in secure integration patterns

Prefer service principals and managed identities with narrow scopes over broad user-delegated tokens.
Use short-lived tokens and rotate client secrets/keys regularly.
Require PKCE (RFC 7636) for public client flows.
Avoid granting tenant-wide admin consent to third-party apps unless absolutely necessary.
When feasible, use SCIM for provisioning and SAML/OIDC for auth, minimizing reliance on long-lived refresh tokens.

Tighten vendor expectations

Ask vendors bluntly: – Do you store refresh tokens? How are they encrypted and segmented?
– What is your refresh token lifetime and rotation policy?
– Do you support token revocation per RFC 7009, and how quickly is access cut after revocation?
– Can we restrict your app by IP, tenant, or resource scopes?
– What telemetry do you provide for admin monitoring (logs, webhooks, SIEM integration)?
– Do you support customer-managed keys (CMK) and per-tenant token segregation?
– What’s your breach response playbook if your token store is compromised?

Align to standards and guidance

NIST Digital Identity Guidelines: SP 800-63-3
OWASP: API Security Top 10
CISA cloud baselines: SCuBA

How attackers actually get these tokens (so you can stop them)

Phishing for initial credentials or sessions, then consenting to malicious apps.
Browser token theft via info-stealers; tokens synced to cloud profiles can multiply exposure.
Abuse of “Consent fatigue”: Users click through app prompts that look benign.
Supply-chain compromise: Vendor backend breached; attacker extracts stored refresh tokens.
OAuth device code flow misuse in “bring your own” desktop tools.

Defenses that work: – Train users to recognize app consent prompts—not just password phishing.
– Require admin pre-approval for high-risk scopes.
– Block legacy OAuth flows without PKCE.
– Monitor for malicious publisher names that mimic trusted apps.
– Treat OAuth logons as “sign-ins” with your identity risk engine.

The identity-centric detective layer you need

Build detections around behaviors, not just events: – First-time consent to a high-scope app by a VIP or service account.
– Token minting from new ASNs, cloud providers, or continents for the same app.
– API call patterns inconsistent with user role (e.g., sales rep pulling all mailboxes).
– Mass download or export events following new app consent.
– Tokens continuing to mint after a user leaves the company (offboarding gap).

Instrument “kill switches”: – Emergency policy to block third-party app tokens at the IdP.
– Rapid revocation automation to yank all refresh tokens for a user/app.
– Quarantine a suspicious app by conditional access while investigating.

Special callouts for high-impact platforms

Microsoft 365 / Entra ID

Lock down admin consent workflows and require security review for “Read/Write all” Graph scopes.
Enable CAE and conditional access for “Cloud apps” to restrict from high-risk locations.
Use Publisher Verification; favor apps with Verified Publisher status.
Review risky OAuth apps in Defender for Cloud Apps App governance.

Google Workspace

Enforce domain-wide restrictions; only allow trusted apps for sensitive scopes.
Monitor OAuth Token Audit Activity in Admin logs.
For high-risk users, require re-auth on sensitive operations; rotate tokens at offboarding.

Salesforce

Restrict Connected Apps by user profiles and IP ranges if possible.
Avoid granting “refresh_token, offline_access” unless essential; set session policies.
Enable Event Monitoring for API calls and data export anomalies.

A pragmatic 90-day roadmap

Days 1–15:
Inventory all OAuth consents across Microsoft, Google, Salesforce, and your top 10 SaaS platforms.
Tag high-risk scopes and vendors; revoke obviously unused or unknown apps.
Turn on available app governance/consent policy controls.
Days 16–45:
Implement anomaly alerts for OAuth behaviors in your SIEM.
Shorten refresh token lifetimes where configurable; disable perpetual refresh.
Update your offboarding to revoke OAuth tokens and app grants by default.
Days 46–90:
Formalize an OAuth governance policy and review board.
Negotiate vendor SLAs for token revocation and telemetry.
Run an incident simulation: stolen refresh token for a critical app—measure MTTD/MTTR.
Publish a simple user guide: “Before you click Allow.”

Common pitfalls to avoid

Blocking everything: Don’t break productivity; start with verified publishers and least privilege.
One-time cleanup: Tokens reappear; schedule quarterly reviews.
Ignoring service accounts: Non-human identities often hold the broadest scopes.
Assuming SSO solves it: SSO centralizes auth, but OAuth grants create separate, durable trust links.
Forgetting vendors: You’re only as strong as the weakest token store in your supply chain.

Executive dashboard: Metrics that matter

Total third-party OAuth apps in use; percent verified/trusted.
Number of grants with offline/refresh scopes; trend over time.
Quarterly revocations of dormant grants; median token lifetime.
Mean time to revoke (MTTR) in last simulation/incident.
Coverage: percent of critical SaaS with OAuth audit logs in SIEM.
High-risk anomaly alerts raised vs. investigated vs. remediated.

FAQs

Q: What exactly is the difference between an access token and a refresh token?
A: Access tokens are short-lived credentials used to access resources (minutes to an hour). Refresh tokens are longer-lived credentials used to obtain new access tokens without user interaction. Attackers prefer refresh tokens because they can silently extend access for long periods.

Q: Doesn’t MFA stop this?
A: MFA protects the initial sign-in and consent event. After that, refresh tokens can continue minting new access tokens without additional prompts. That’s why token governance is essential.

Q: If we use SSO and strong conditional access, are we safe?
A: Safer, not safe. SSO centralizes auth, but OAuth grants create their own trust relationships with third-party apps that can bypass password/MFA prompts. Conditional access helps but must be paired with app governance, token expiration, and revocation.

Q: How do we even find all these tokens?
A: Start with your identity providers’ consent and enterprise app pages (Entra ID, Google Workspace), plus each critical SaaS’s “Connected Apps” view. Use Microsoft’s App governance for M365 and Google’s OAuth app access controls. Ingest audit logs into your SIEM to close visibility gaps.

Q: Can we just block all third-party app consents?
A: You can, but it will likely break business workflows. A better approach is default-deny with a clear review process, verified publishers only, and least-privilege scopes. Auto-expire consents and require re-justification.

Q: Do we need to worry about service accounts?
A: Absolutely. Non-human identities often hold the broadest scopes and the longest-lived tokens. Govern them like crown jewels: narrow scopes, IP/location restrictions, short lifetimes, and strict monitoring.

Q: What should we ask vendors about token security?
A: Ask whether they store refresh tokens, how they encrypt and segregate them, their rotation and expiration policies, support for RFC 7009 revocation, detection of anomalous access, and how quickly they can revoke in bulk during an incident.

Q: Is this just a Salesforce or Microsoft/Google issue?
A: No. OAuth is a cross-ecosystem pattern. Any SaaS that allows third-party app integrations and background access is in scope. The risk stems from how tokens and grants are managed, monitored, and revoked—not from a single vendor.

Q: Where can I learn more about secure OAuth practices?
A: Start with the standards: RFC 6749 (OAuth 2.0), RFC 7009 (Token Revocation), and RFC 7636 (PKCE). For applied guidance, see OWASP API Security and CISA’s SCuBA baselines.

The bottom line

The breach path that hit hundreds of Salesforce environments didn’t rely on zero-days or exotic malware. It rode in through something most companies consider routine: OAuth tokens issued to trusted apps—many of them AI assistants and automations employees rely on every day.

This is the backdoor attackers already know and love. Close it by making OAuth governance a first-class citizen in your identity program: – See every app and grant.
– Cut token lifetimes and kill dormant access.
– Monitor for anomalous app behavior.
– Demand revocation and telemetry from vendors.
– Practice revoking at scale before you have to.

You don’t need to choose between productivity and security. You need visibility, policy, and automation. Start with your highest-impact apps this month—and turn Shadow Identity into governed identity.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!