SaaS and OAuth Integration Security
Most company data no longer sits on servers the company runs. It sits in Salesforce, Microsoft 365, Google Workspace, Slack, GitHub, Snowflake, Workday and a few hundred other SaaS apps, connected to each other by OAuth tokens nobody reviews. Verizon's 2026 Data Breach report found third parties involved in 48% of breaches, up from 30%. The big data-theft campaigns of 2024–2026 (Snowflake customers, Salesforce vishing, Salesloft Drift) didn't break any SaaS platform; they used valid logins and tokens. This page explains where SaaS security actually fails and what to do about it.
Last verified2026-10
The SaaS Shared-Responsibility Line
What is this?The SaaS vendor secures the platform: servers, patching, the application code. You own everything about how you use it: who can log in, with what MFA, what they can see, which integrations are connected, how data is shared, and whether anyone reads the audit logs.
Infrastructure, application vulnerabilities, availability, encryption at rest, the platform's own staff access
Identities and MFA, roles and permissions, integrations and API tokens, sharing settings, data retention, log collection and alerting
Tenant configuration nobody owns: local admin accounts that bypass SSO, old API keys, connected apps with broad scopes, public sharing links
Why it matters"The vendor is SOC 2 certified" is about the vendor's side of the line. It says nothing about your tenant's settings.
Identity Is the Perimeter
What is this?For SaaS there is no network to defend. The front door is the login, and usually the identity provider (Okta, Entra ID, Google) that every app trusts through single sign-on (SSO).
How it works
, otherwise one forgotten local admin account bypasses all your MFA and Conditional Access.
(FIDO2 security keys, passkeys) for admins at least; help-desk resets need strong identity checks, since social engineering of the help desk is now a standard entry route.
a stolen session cookie or refresh token skips MFA entirely. Shorter sessions, device binding and re-authentication for sensitive actions limit what a stolen token is worth.
its admins, its support access, and its logs.
📰Real incident — Snowflake customers (2024). A financially motivated group (UNC5537) logged into about 165 organisations' Snowflake accounts, including AT&T, Ticketmaster and Santander, with usernames and passwords harvested by infostealer malware, some stolen years earlier. Snowflake itself wasn't breached: the accounts simply had no MFA and the passwords had never been rotated. Snowflake later made MFA mandatory by default. Lesson: one data-warehouse login without MFA can hold your entire customer base.
📰Real incident — Okta support system (2023). An attacker used a service account whose credentials an Okta employee had saved in a personal Google profile to get into Okta's customer-support system. They downloaded HAR files (browser recordings) that customers had uploaded for troubleshooting, which contained live session tokens, and used them against customers including BeyondTrust and Cloudflare. Lesson: support artefacts carry credentials, so scrub tokens from HAR files and logs before sharing.
OAuth Integrations: The Connections Nobody Reviews
What is this?When you click "Connect to Salesforce" in a sales tool, Salesforce issues that tool an OAuth token with certain scopes. The tool can then read or write your data via API, without your password, until the token is revoked. Every SaaS tenant accumulates dozens of these SaaS-to-SaaS connections, often granted by individual employees.
Why it mattersAn integration token:
- bypasses MFA and SSO (it already passed them once),
- often has broad scopes ("full access", "read all mail"),
- doesn't expire when the employee who granted it leaves,
- generates API traffic that looks like normal automation.
So a breach at a small integration vendor is a breach of every customer's connected data.
In practiceGitHub is a good place to see it: list the apps installed on your organisation and what each can touch.
$ gh api /orgs/acme/installations --jq '.installations[] | {app: .app_slug, repos: .repository_selection, perms: .permissions}'
{"app":"ci-helper","repos":"selected","perms":{"contents":"read","statuses":"write"}}
{"app":"old-deploy-bot","repos":"all","perms":{"contents":"write","administration":"write","secrets":"write"}} ← every repo, can edit secrets, nobody remembers installing it📰Real incident — Salesloft Drift (2025). Attackers (tracked by Google as UNC6395) stole OAuth tokens that Salesloft's Drift chatbot integration held for its customers' Salesforce tenants. Over about ten days they used the tokens to export data from hundreds of companies' Salesforce instances, including several security vendors, then searched the exported support cases for AWS keys, passwords and Snowflake tokens to pivot further. No customer was phished and no MFA was bypassed. Lesson: inventory integrations, limit their scopes, and keep secrets out of support tickets.
📰Real incident — Salesforce vishing (2025). A group Google tracks as UNC6040 phoned employees pretending to be IT support and talked them into authorising a modified "Data Loader" connected app in their company's Salesforce. The app then bulk-exported customer data for extortion. Google's own Salesforce instance was among the victims. Lesson: restrict who can authorise connected apps, and alert on new ones.
SaaS Security Posture: What to Check
What is this?SaaS Security Posture Management (SSPM) tools continuously check tenant settings across apps. Whether you buy one or script it, the checks are the same:
🎯On the job. When a SaaS vendor or integration you use announces a breach, don't wait for their investigation:
- Revoke and reissue every token and API key that vendor held.
- Search that vendor's access logs in your tenant for unusual exports, IPs and user agents.
- Assume any secret stored in the exposed data (support tickets, CRM notes) is compromised, and rotate it.
- Check your contracts for notification obligations both ways.
Detection in SaaS
What is this?SaaS attacks look like normal use, so detection relies on volume, novelty and context in each app's audit logs:
report or API exports far above the user's or integration's baseline (the Snowflake and Salesforce campaigns).
with high-risk scopes, especially right after a phone call or from a new device.
(VPN providers, Tor, hosting ranges) for accounts that normally come from the office or a managed device.
for an integration that always runs from the vendor's fixed ranges.
new admins, SSO or MFA settings loosened, audit logging disabled.
Interview Questions
The vendor secures the platform: infrastructure, application vulnerabilities, availability. We own everything about our tenant: who can log in and with what MFA, permissions, connected integrations and their tokens, sharing settings, and collecting and reviewing the audit logs. The 2024 Snowflake campaign is the example: Snowflake wasn't breached, but about 165 customers had accounts without MFA and with passwords stolen by infostealers, which was entirely on the customer side of the line.
An integration token has already passed SSO and MFA, often carries broad scopes, doesn't expire when the employee who granted it leaves, and its API traffic looks like normal automation. So a breach at a small integration vendor becomes a breach of every connected customer, which is what happened with Salesloft Drift in 2025. I manage them with an inventory of every connected app, its scopes, owner and last use, by stopping users from granting high-risk scopes without admin approval, by removing unused integrations, and by alerting on new grants and on token use from unexpected IPs.
I don't wait for their investigation. I revoke every token and API key that vendor held in our tenants and reissue only what's needed, then search our audit logs for that integration's activity: bulk exports, new IPs, unusual queries. I treat any secret stored in the exposed data as compromised, because in the Drift campaign attackers mined exported support cases for AWS keys and Snowflake tokens. Then I check contractual and regulatory notification duties and reassess the vendor's access scope before reconnecting.
Through the app's own audit and event logs exported to the SIEM, since there's no network signal. The strongest signals are export or API volume far above a user's or integration's baseline, new connected apps being authorised, especially after unusual help-desk calls, and logins or token use from VPN, Tor or hosting providers. I'd also watch admin changes like loosening MFA or disabling logs. The 2025 Salesforce vishing campaign showed up exactly as a new Data Loader-style app followed by bulk exports.