What are OAuth app risks?

By Identra · Updated July 12, 2026

An OAuth app risk is the exposure created when a third-party application holds a delegated grant to act inside your SaaS environment. Because tokens persist long after consent, attackers exploit consent phishing, over-broad scopes, and forgotten grants to read mail, files, and data without ever stealing a password or triggering MFA.

Key numbers

More than 50 impersonated Microsoft OAuth applications were observed across email campaigns, including fakes of Adobe, DocuSign, RingCentral, and SharePoint (Proofpoint, 2025)
47.2% of OAuth-connected apps in enterprise Google Workspace environments showed no active usage in the prior 90 days (Material Security, 2026)
1,064 apps held live tokens with zero active users, and 463 of those held sensitive or restricted scopes (Material Security, 2026)

Why do OAuth grants carry risk?

OAuth exists to solve a real problem: letting one application act inside another without sharing a password. When a user clicks Allow on a consent screen, the platform issues the app a token scoped to specific permissions, such as reading mail or editing files. That token is a non-human credential. It works from anywhere, it does not require the user to be present, and in most configurations it is not challenged by MFA again.

The risk comes from persistence and invisibility. A grant approved in thirty seconds can remain valid for years, surviving password resets and often surviving offboarding workflows that only think about human logins. Most organizations have no complete inventory of which apps hold grants, what scopes those grants carry, or whether anyone still uses them. Each forgotten grant is standing access into email, files, calendars, and source code.

What is consent phishing?

Consent phishing flips credential theft on its head. Instead of stealing a password, the attacker registers a legitimate-looking OAuth app, often impersonating a known brand, and tricks the victim into clicking Allow. The platform then hands the attacker a valid token. No password was stolen, MFA was satisfied, and the access looks like normal API traffic.

This is not a niche technique. Proofpoint documented email campaigns in 2025 that used more than 50 fake Microsoft OAuth applications, including fakes of Adobe, DocuSign, RingCentral, and SharePoint, as lures that redirected victims to credential and session-cookie phishing pages built with attacker-in-the-middle kits such as Tycoon. That chain ends in account takeover through a stolen session, which is different from access obtained through malicious consent alone.

Scope creep and unused grants

Even fully legitimate apps accumulate risk. Developers frequently request broader scopes than the feature needs, because asking once for full mailbox access is easier than shipping incremental consent. Users approve whatever is on the screen. The result is a population of apps whose permissions far exceed their function, and whose blast radius on compromise is the entire account.

The bigger problem is what happens after adoption fades. Material Security's 2026 analysis of 22,332 OAuth-connected apps across 21 enterprise Google Workspace environments found that 47.2 percent showed no active usage in the prior 90 days, and 1,064 apps had zero active users but still held live tokens. Of those zombie grants, 463 carried sensitive or restricted scopes, including full Gmail and Drive access on accounts nobody was watching. A dormant grant is pure downside: no business value, full attack surface.

SaaS-to-SaaS access nobody sees

The fastest-growing slice of OAuth risk involves no human at all. SaaS platforms authorize each other directly: the CRM connects to the data warehouse, the AI notetaker connects to the calendar and mail, the automation platform connects to everything. These machine-to-machine grants run outside the browser, outside the identity provider's session controls, and outside most security tooling, which watches human logins.

AI adoption is accelerating this quietly. In the same Material Security dataset, 91 percent of AI and automation apps first appeared within the previous 16 months, and more than half held sensitive or restricted scopes. Each of these integrations is a supply chain dependency: if the vendor holding your tokens is breached, the attacker inherits every grant that vendor was given, across every customer.

Consent phishing
How it starts
User approves a malicious app on a real consent screen
Why it persists
Token stays valid after password resets and MFA challenges
Scope creep
How it starts
App requests broader permissions than its feature needs
Why it persists
Nobody re-reviews scopes after the initial approval
Unused grants
How it starts
Adoption fades or the employee leaves
Why it persists
Revocation is manual and no owner is assigned
SaaS-to-SaaS access
How it starts
Platforms authorize each other with no human session
Why it persists
Traffic looks like normal API calls and evades login monitoring

Risk	How it starts	Why it persists
Consent phishing	User approves a malicious app on a real consent screen	Token stays valid after password resets and MFA challenges
Scope creep	App requests broader permissions than its feature needs	Nobody re-reviews scopes after the initial approval
Unused grants	Adoption fades or the employee leaves	Revocation is manual and no owner is assigned
SaaS-to-SaaS access	Platforms authorize each other with no human session	Traffic looks like normal API calls and evades login monitoring

How do you reduce OAuth app risk?

OAuth risk yields to lifecycle discipline more than to any single control. The goal is to know every grant, justify every scope, and revoke everything that fails either test.

Inventory every OAuth grant across your identity providers and major SaaS platforms, including app publisher, scopes, and last-used date
Require admin consent for high-risk scopes so users cannot unilaterally approve mail, file, or directory access
Restrict consent to verified publishers to blunt look-alike apps used in consent phishing
Revoke grants that show no activity for a defined window, and re-review surviving grants on a schedule
Monitor token usage at runtime, since a grant that suddenly changes volume, geography, or data accessed is a live incident, not a hygiene item

How Identra thinks about it

Identra treats every OAuth grant as a non-human identity with a lifecycle, not a checkbox a user clicked once. The static questions, which apps exist and what scopes they hold, only cover half the problem. The other half is behavioral. A token that has been dormant for six months and suddenly starts pulling mailboxes at 3 a.m. is indistinguishable from normal API traffic to most tools. Identra collects OAuth grants with the app, its permissions and who granted them, sorts apps by what they can reach, and lets an analyst revoke risky grants, with every result recorded.

Go deeper: The Non-Human Majority

Frequently asked questions

How do I see what OAuth apps have access to my organization's data?

Each platform exposes its own grant inventory: Microsoft Entra lists enterprise applications and their delegated permissions, Google Workspace shows connected apps and OAuth scopes per user, and GitHub, Salesforce, and Slack have equivalent admin views. Pull publisher, scopes, and last-used dates from each, then merge them, because no single console shows SaaS-to-SaaS grants across your whole estate.

Does revoking an OAuth grant immediately cut off access?

Revoking a grant invalidates the refresh token, so the app can no longer mint new access tokens. Existing access tokens may keep working until they expire, typically within an hour on major platforms. For a suspected compromise, revoke the grant, expire active sessions where the platform supports it, and check audit logs for what the token accessed before revocation.

Why doesn't MFA stop consent phishing?

Because the victim performs a completely legitimate login, MFA included, and then authorizes the attacker's app on a real consent screen. The platform issues the app a valid token as designed. No credential is stolen, so there is nothing for MFA to block. The defense is controlling which apps can request consent, not strengthening the login itself.

What are zombie OAuth grants?

Zombie grants are OAuth authorizations that remain live after the app stopped being used or the approving employee left. Material Security's 2026 analysis found 47.2% of OAuth-connected apps in enterprise Google Workspace environments showed no usage in 90 days, and 463 zero-user apps still held sensitive scopes. They carry full attack surface with no business value.

Compare

All comparisons →