Securing SaaS-to-SaaS Integrations: The OAuth Sprawl Problem in 2026

When a user clicks "Sign in with Microsoft" or "Connect with Google" on a third-party application, the application requests specific scopes (Mail.Read, Files.ReadWrite.All, offline_access, etc.). The user is shown a consent screen. If the user clicks Accept, the application receives a token that grants exactly those scopes.

Critical properties of OAuth consent that most users don't understand:

• Persistent — the token works until the user explicitly revokes it. Password change does not revoke. MFA enforcement does not revoke.
• Scope-bounded but often broad — Mail.Read means full mailbox read access, not just the email the app was helping with
• Bypasses Conditional Access in many cases — the OAuth token authenticates without re-evaluating the original sign-in policy
• Often requested with offline_access — meaning the application can act on the user's behalf when the user is not even logged in

Illicit Consent Grant Phishing

Attacker creates a malicious application (or hijacks an existing one), crafts a phishing email that lures the victim to a "Sign in with Microsoft" page, and the victim consents. Attacker now has persistent mailbox access without the password and without triggering MFA. This pattern was used in numerous 2024-2025 breaches and is rising in 2026.

Compromised Legitimate App

An app that 50 of your users consented to in 2023 gets breached in 2026. The attacker now has access to the data of all 50 users — and you may not even know which apps your users have consented to.

Departed Employee Persistence

An employee leaves. You disable their account. But the OAuth grants they made to third-party apps may remain valid, and the apps may now act on the disabled account's behalf for whatever data they had access to.

OAuth Token Theft via AiTM

Adversary-in-the-middle phishing kits increasingly target OAuth flows in addition to standard sign-ins, capturing tokens for direct API access — see our MFA bypass attacks 2026 coverage.

Layer 1: Disable User Consent for Risky Permissions

In Microsoft Entra ID, configure user consent settings to restrict end-user consent to verified publishers only and to low-risk permissions only. Anything requiring Mail.Read, Files.ReadWrite.All, Sites.FullControl, or similar high-impact scopes requires admin consent.

For most Texas SMBs, this single setting eliminates 60-80% of new OAuth risk overnight. Users can still consent to low-risk apps; admins review the high-impact requests.

Layer 2: Admin Consent Workflow

When a user requests admin consent for a high-impact app, route the request through an admin review workflow (built into Entra ID). The reviewer evaluates: is this a legitimate business need? Is the publisher verified? What scopes does the app require, and does it actually need all of them? Can the same need be met with a less-invasive alternative?

Layer 3: Quarterly OAuth App Inventory Review

Run a quarterly report of all consented applications. For each:

• Is the application still in use? (Microsoft Graph activity logs show this.)
• Is the publisher still trustworthy? (Has the publisher been breached or sold?)
• Are the scopes still appropriate?
• Are there users who consented and have since departed?

Revoke unused or stale grants.

Layer 4: Risky App Detection

Microsoft Defender for Cloud Apps (included in M365 E5 — see our Defender family decision guide) detects suspicious OAuth applications based on permissions requested, publisher reputation, age, and behavior. Alerts on new high-risk grants in real time.

Third-party tools like Push Security, Valence Security, and Adaptive Shield provide multi-IdP OAuth governance for organizations with both Microsoft and Google identity stacks.

Layer 5: Offboarding Includes OAuth Revocation

Standard offboarding: disable account, recover device, archive mailbox. Add: revoke all OAuth grants the user made. Microsoft Graph PowerShell can list and revoke them programmatically.

Conditional Access policies can require additional context for OAuth flows. Specifically: require the OAuth-requesting application to come from a trusted IP range, require the user's session to be from a managed device, require a recent re-authentication. This raises the bar on illicit consent grant phishing significantly.

• End-user training on consent screens (they should know what they are clicking)
• Sanctioned-app catalog (give users an easy path to legitimate integrations)
• SaaS application management at the procurement layer (knowing which SaaS your organization actually uses)

For Texas SMBs that have not audited OAuth consent: the immediate-day-one action is disabling end-user consent for high-impact permissions in Entra ID. Then run the inventory of currently-consented apps. The first audit usually surprises everyone — including the apps consented by people who left two years ago.

Related reading: ITDR for Texas SMBs, M365 Copilot security, M365 managed services.

• Houston managed IT
• The Woodlands cybersecurity
• Sugar Land cybersecurity
• Katy managed IT