56% of OAuth-connected apps have overly permissive access to corporate data. Learn the top OAuth security risks and how to build a governance policy.
OAuth (Open Authorization) is the protocol that powers "Sign in with Google" and "Connect to Microsoft 365" buttons across the SaaS ecosystem. It's designed to let users grant third-party applications access to their data without sharing their password.
Here's the simplified flow:
OAuth solved a real problem: it eliminated the need for users to share passwords with third-party apps. But it created a new one. Every OAuth grant is a persistent, often over-permissioned backdoor into your corporate data.
The consent screen — the user's one chance to evaluate what they're authorizing — is typically clicked through in seconds. Most employees don't read it. Even those who do often lack the technical context to evaluate whether "Read, compose, send, and permanently delete all your email" is a reasonable permission for a meeting scheduling app.
The numbers paint a concerning picture:
Each of these OAuth grants represents a connection between your corporate data and a third-party application. And unlike traditional access controls, OAuth grants are:
OAuth permissions are defined in "scopes" — categories of access that range from narrow (read-only access to profile information) to extremely broad (full read/write access to all data).
Many applications request far more access than they need. A project management tool might request:
gmail.readonly — Read all emaildrive — Full access to Google Drive filescalendar — Read and write calendar eventscontacts.readonly — Read all contactsDoes a project management tool need to read all your email? Almost certainly not. But developers request broad scopes because it's easier than implementing fine-grained access, and users rarely push back.
The risk: An application with overly broad permissions can access far more data than its functionality requires. If that application is compromised, the attacker inherits all of those permissions.
OAuth tokens persist until they are explicitly revoked. When an employee stops using a SaaS application, the OAuth connection often remains active indefinitely.
These dormant tokens are particularly dangerous because:
The risk: Dormant OAuth connections are forgotten backdoors. An application an employee used once, two years ago, may still have full access to their email and files.
Consent phishing (also called OAuth phishing or illicit consent grant attacks) is a growing attack vector where attackers create malicious applications designed to trick users into granting OAuth access.
The attack flow:
Why this is hard to detect: Unlike traditional phishing that steals credentials, consent phishing doesn't trigger password alerts, MFA challenges, or login anomaly detection. The employee authenticated legitimately. The access grant looks like any other OAuth connection.
The risk: A single successful consent phishing attack can give an attacker persistent read/write access to email, files, and calendar data. Because it uses legitimate OAuth, it bypasses most security controls.
When employees use their corporate Google or Microsoft account to sign into third-party applications, they create OAuth connections that are invisible to most security tools. This is a subset of the broader shadow IT problem. These shadow OAuth grants:
The risk: Shadow OAuth grants are the intersection of shadow IT and OAuth security. They combine the visibility challenge of shadow IT with the persistent access risk of OAuth, creating blind spots that are difficult to detect and remediate.
OAuth tokens can be stolen through several vectors:
The risk: A stolen OAuth token provides direct access to the user's data without requiring their credentials or triggering MFA. Token-based access is often indistinguishable from legitimate application activity in log files.
A mid-market company uses a popular task management application. 80 employees have granted it OAuth access to Google Workspace with "read and send email" and "manage Drive files" permissions.
The task management vendor suffers a data breach. Attackers extract OAuth tokens from the vendor's database. Within hours, they:
Impact: Massive data exfiltration, compromised email, and the ability to impersonate employees — all from a single vendor breach.
An attacker creates an application called "Microsoft Security Alert" that requests OAuth access to Microsoft 365. They send targeted emails to employees at a financial services company.
12 employees click "Allow." The attacker now has access to their email and OneDrive files. They:
Impact: The attack is discovered only when a client reports suspicious activity. By then, months of confidential data have been exfiltrated. No malware was installed, no credentials were stolen, no traditional alert was triggered.
A senior product manager leaves the company. IT disables their Google Workspace account. But over two years of employment, they granted OAuth access to 15 third-party applications.
Several of these OAuth tokens remain valid even after the IdP account is disabled (depending on the vendor's implementation). Data that was synced to third-party applications remains accessible. One of the applications — a note-taking tool — contains detailed product roadmaps and competitive analysis.
Impact: Sensitive strategic data remains in uncontrolled third-party applications long after the employee leaves. A comprehensive SaaS offboarding process is essential to prevent this.
A systematic OAuth audit should be performed quarterly at minimum. Here's how:
Pull a complete list of OAuth grants from your identity provider:
Document each grant with: application name, user, permissions scope, date granted, last used.
Evaluate each OAuth-connected application against these criteria:
| Risk Factor | Low Risk | Medium Risk | High Risk |
|---|---|---|---|
| Permissions | Read-only, limited scope | Read-write, moderate scope | Full access to email/files/admin |
| Vendor security | SOC 2 certified, established vendor | Known vendor, no certification | Unknown vendor, no security info |
| User count | 1-2 users | 3-10 users | 10+ users |
| Data sensitivity | No sensitive data access | Accesses some sensitive data | Accesses PII, financial, or IP |
| Activity status | Active, regular use | Intermittent use | Dormant (no use in 90+ days) |
Based on your risk classification:
After the initial audit, implement controls to prevent the same problems from recurring:
A practical OAuth governance policy should cover:
Define acceptable and unacceptable OAuth scopes:
Always blocked (require security review and exception approval):
Allowed with approval:
Auto-approved:
Before approving an OAuth-connected application:
Most OAuth security incidents start with users who don't understand what they're authorizing. Include in your security awareness training:
Add OAuth-specific scenarios to your incident response playbook:
Manual OAuth audits are necessary but not sufficient. The OAuth landscape changes daily as employees grant new permissions. Automated monitoring fills the gap:
SaaS management platforms that integrate with Google Workspace and Microsoft 365 can provide:
This visibility is the foundation of OAuth governance. Without it, you're relying on manual audits that are outdated before they're finished.
OAuth is a convenience that has become a systemic security risk. Every "Sign in with Google" click creates a persistent connection between your corporate data and a third-party application that may or may not deserve that access.
The solution is not to block OAuth entirely — that would break modern SaaS workflows. The solution is visibility, governance, and continuous monitoring:
Most organizations start with an audit that reveals far more OAuth connections than anyone expected. That moment of discovery is the beginning of real OAuth security. European companies should also consider how OAuth governance fits into NIS2 compliance and broader SaaS security strategy.
Want to see every OAuth connection in your environment? Book a demo and get a complete OAuth risk assessment in 15 minutes.
NIS2 is the biggest EU cybersecurity regulation since GDPR — with major implications for SaaS. Learn what IT leaders need to know about compliance.
Learn proven SaaS data protection strategies, from classification to DLP, that keep your cloud data secure and compliant with regulations.
Learn how to identify, assess, and mitigate SaaS risks with proven frameworks. Essential guide for CISOs managing cloud security and vendor risk.