OAuth Consent Phishing: The MFA Blind Spot Security Teams Need to Recheck

The phishing click security teams used to worry about was the one that handed over a password. The newer version can be quieter: a user approves an OAuth consent prompt, believes they have completed a normal workflow, and unintentionally gives an attacker or risky app a durable path into business data.

That is the problem behind OAuth consent phishing, sometimes called OAuth grant abuse. The user may authenticate on the legitimate identity provider. They may complete multifactor authentication. The prompt may even appear as part of a familiar Microsoft 365, Google Workspace, CRM, or productivity workflow. The risk sits in what happens after the user clicks Accept.

In one recent example reported by security researchers, a phishing-as-a-service platform called EvilTokens was described as targeting Microsoft 365 users through a device-code style flow. Victims were reportedly asked to enter a short code on a legitimate Microsoft device login page and complete their normal MFA challenge. The concern is that, after that workflow, the operator could receive an OAuth token with access tied to the permissions the user approved. The exact scope and persistence depend on the tenant, app, and policy configuration, so defenders should treat those details as environment-specific rather than universal.

The broader lesson is still clear. MFA is built to challenge authentication. OAuth consent is an authorization decision. When those two moments are treated as the same security event, a meaningful gap opens.

Why MFA Does Not Fully Cover OAuth Consent

Traditional credential phishing has a familiar pattern. A user gives up a username and password, and the attacker tries to replay those credentials somewhere else. Modern identity stacks often challenge that replay with MFA, conditional access checks, device posture rules, impossible-travel logic, and sign-in anomaly detection.

OAuth consent phishing works differently. The user may sign in to the real identity provider and pass the expected MFA challenge there. After that, the user approves an app permission request. If the request is malicious, compromised, or overly broad, the resulting grant can give the app access to mail, files, calendars, contacts, or other SaaS data within the limits of the approved scopes.

That distinction matters because MFA has already done its job by the time consent is granted. It proved that the person at the keyboard could complete the authentication challenge. It did not prove that the app being authorized is safe, necessary, correctly scoped, or still trustworthy tomorrow.

A token issued through this flow is not the same thing as a stolen password. It is created by the identity provider and tied to the permissions approved through the consent process. Depending on configuration, some tokens or grants can remain useful after a password reset unless the organization also revokes the relevant sessions, grants, or refresh tokens. Security teams should verify the exact behavior in their own identity platform instead of assuming that password rotation closes every path.

That is why incident response playbooks built around password resets can miss part of the cleanup. If the problem is an OAuth grant, the response needs to include token and consent review, not just account recovery.

The Consent Screen Has Become Too Routine

OAuth was designed to let users and organizations authorize apps without sharing passwords. That remains useful. The problem is that consent prompts now appear in far more places than many original governance models expected.

A worker may approve access for an AI note taker, a browser extension, a sales automation tool, a document utility, a scheduling assistant, or a reporting connector. Each request can look ordinary in isolation. Each may ask for a scope that sounds narrow enough to accept quickly. Over time, those decisions create a web of app-to-user-to-data relationships that few teams can inspect from a single SaaS console.

Consent language also tends to understate operational impact. A permission that says an app can read mail may include messages, attachments, shared threads, and sensitive business context. A permission that allows access when the user is not present can support useful automation, but it can also create a longer-lived exposure if the app is abused. The practical risk depends on the scope, the identity approving it, the sensitivity of reachable data, and whether the organization can detect and revoke the grant quickly.

Attackers do not need every user to approve a dangerous request. One high-value identity can be enough. A finance employee, executive assistant, sales operations manager, IT admin, or product leader may sit at the intersection of calendars, documents, customer records, contracts, and internal planning material.

How Cross-App Risk Builds Through One Identity

The most serious problem is not always a single OAuth grant. It is the combination of grants and integrations that collect around a human or non-human identity.

Consider a finance user who approves an AI meeting assistant with access to calendar and mailbox data. Later, the same person approves a productivity tool with access to shared drive content. A separate CRM enrichment integration touches customer data. Each decision may have seemed reasonable at the time. No single application owner necessarily approved the combined reach created through that user.

Security teams often describe this as a toxic combination: a risk pattern formed across applications, identities, scopes, integrations, and agents. It is difficult to see from one application’s audit log because the risk does not live entirely inside that application. It lives in the bridge between systems.

Model Context Protocol servers and AI-agent connectors are increasingly discussed in this same risk category. The exact threat model varies by implementation, but the governance issue is familiar: an agent or connector receives scoped access once and can then act across systems in ways that may not be obvious to the user who approved it.

The 2025 Salesloft-Drift incident showed why downstream connector risk deserves board-level attention. Customers had approved integrations for legitimate business reasons, but a compromise in the connector ecosystem created wider exposure across connected Salesforce environments. The specific mechanics differ from consent phishing, but the lesson overlaps: trusted integrations can become high-impact access paths.

What Security Teams Should Look For

OAuth consent phishing is not solved by telling users to be more careful. User training helps, but the decision is often too technical for a worker to evaluate in real time. A better approach treats consent as a security control plane, with policies, monitoring, and response procedures comparable to authentication.

Useful review questions include:

• Which users can approve third-party applications without admin review?
• Which OAuth grants have high-risk scopes such as mail, file, calendar, directory, offline, or admin-level access?
• Which apps have not been used recently but still retain access?
• Which grants were created by high-value users such as executives, finance staff, administrators, developers, and sales operations teams?
• Which non-human identities, service accounts, AI agents, and automation tools can reach sensitive SaaS data?
• How quickly can the team revoke a suspicious grant without disabling the entire user account?

That last question is especially important. Time-to-revoke is becoming a practical identity security metric. If the security team can detect a risky OAuth grant but needs days to identify the owner, understand the scope, coordinate with an app team, and remove access, the attacker’s window remains wide.

For many organizations, the first improvement is simply inventory. Security teams need a current list of approved enterprise apps, user-consented apps, delegated permissions, application permissions, refresh-token behavior, and exceptions. Without that, teams are left investigating consent risk only after an incident.

Policy Changes That Reduce OAuth Grant Abuse

The right controls depend on the identity provider and SaaS estate, but the defensive pattern is consistent: limit who can approve access, reduce unnecessary scopes, detect abnormal grants, and revoke access precisely.

Common measures include:

1. Restrict user consent for unverified or risky applications, especially apps requesting sensitive scopes.
2. Require admin approval for high-impact permissions such as mailbox access, offline access, directory access, file access, and tenant-wide privileges.
3. Review existing grants on a schedule and remove unused or stale applications.
4. Monitor for new grants involving high-risk users, unusual publishers, broad scopes, or unexpected geographies.
5. Build incident playbooks that include OAuth grant revocation, token invalidation, and connected-app review.
6. Apply conditional access and app governance policies where the platform supports them.
7. Track AI agents, MCP servers, browser extensions, and SaaS connectors as part of the same third-party access inventory.

The goal is not to block every integration. That would push teams toward shadow IT. The goal is to make app authorization visible enough that risky grants can be challenged before they become incidents, and removable enough that response does not depend on broad account shutdowns.

Where AI Security and Identity Platforms Fit

A growing set of identity security, SaaS security, and AI security platforms is trying to address this operational gap. The useful ones focus less on static compliance snapshots and more on the live graph of identities, apps, grants, agents, scopes, and data access.

In practical terms, that means discovering OAuth grants and AI-agent connections as they appear, mapping each grant back to the identity that approved it, identifying risky scope combinations, and giving teams a way to revoke access at the token or application level. This is different from disabling a user account. It targets the relationship that created the exposure.

Reco is one example in this category. Its positioning centers on AI agent security, identity governance, threat detection, and an identity knowledge graph that connects human and non-human identities with SaaS applications, OAuth grants, and integrations. For a buyer evaluating this type of platform, the important questions are less about category labels and more about operational coverage:

• Can it discover user-consented and admin-consented OAuth grants across the SaaS estate?
• Does it show which identities and data sets each grant can reach?
• Can it detect risky combinations across apps, agents, and integrations?
• Does it support token-level or grant-level revocation?
• Can it produce an actionable queue for security operations rather than another static report?

Those capabilities matter because OAuth consent phishing lives in the runtime layer. It is created through normal user and app behavior, not only through obvious malicious sign-ins.

The Practical Takeaway

OAuth consent phishing is dangerous because it does not have to look like a break-in. A user can authenticate correctly, pass MFA, approve a prompt, and still create an access path that the security team did not intend to allow.

That does not make MFA obsolete. MFA still reduces credential theft risk and remains a core identity control. It does mean MFA should not be treated as the outer edge of SaaS security. Consent, tokens, integrations, browser extensions, and AI-agent connections now need their own visibility and response discipline.

For CISOs and security architects, the next step is concrete: inventory the grants, rank the scopes, restrict approval paths, monitor new consent events, and measure how quickly the team can revoke access when something looks wrong. The phishing click has moved deeper into the authorization layer. The controls need to follow it.