OAuth Consent Phishing: How One Approval Gives Attackers Persistent Access

OAuth consent phishing is a social engineering attack in which a victim is tricked into approving a malicious third-party application through a legitimate login screen (Microsoft, Google, or Salesforce). Instead of stealing a password, the attacker steals authorization. Once the victim clicks “Accept,” the app receives an access token and a refresh token that let it read email, files, and contacts through official APIs. Because no credential is entered, multi-factor authentication (MFA) is never triggered, and the access survives password changes.

That single design detail is why this technique is spreading fast. The defenses most organizations rely on, strong passwords and MFA, were built to stop credential theft. OAuth consent phishing does not need a credential.

Key takeaways

• OAuth consent phishing steals authorization (a token), not your password.
• It bypasses MFA and keeps working after a password reset.
• The attacker reads email, files, and contacts through official APIs, which is often the launchpad for business email compromise (BEC).
• Only an administrator removing the app’s consent actually stops it.
• The most reliable defense is restricting user consent and training people to recognize the prompt.

What is OAuth consent phishing?

OAuth 2.0 is the standard that lets you sign in to a third-party app “with Microsoft” or “with Google” without sharing your password. When you approve an app, the identity provider issues that app a token that represents your permission to access specific data.

Consent phishing abuses that trust. An attacker registers an app with an official-looking name, for example “IT Security Verification” or “Salesforce Data Loader,” and sends the victim a link to the provider’s real consent screen. The page is genuinely hosted by Microsoft or Google, the URL is legitimate, and the sign-in flow passes every technical check including SPF, DKIM, and MFA. The only malicious element is the app requesting access and the user granting it.

The technique appears in the MITRE ATT&CK framework and is sometimes called an “illicit consent grant” attack.

Its close relative, device code phishing, abuses the OAuth device authorization flow used by TVs and CLI tools. The two share the same outcome: the attacker ends up with valid tokens rather than a password.

Anatomy of a consent screen: what the victim actually sees

The screenshot below is an OAuth consent phishing lure built inside the Keepnet AI Phishing Simulator for a controlled awareness test. It is a safe simulation, not a live attack, and it mirrors exactly what a real consent-phishing prompt looks like.

Look at the warning signs a trained user should catch, all of them visible on the real thing:

• App name is generic and authoritative. “IT Security Verification” sounds like something your own IT team would send. Attackers pick names that discourage questions.
• “unverified” and “This application is not published by Microsoft.” The provider itself is telling you it does not vouch for this app. Most users read past it.
• The permissions are the payload. “Sign you in and read your profile” seems harmless. “Maintain access to data you have given it access to” is the dangerous one: it is the offline_access scope, which grants a refresh token so the app keeps working after you close the browser and after you reset your password.
• “Consent on behalf of your organisation.” If a user with admin rights ticks this box, the app gains access for the entire tenant, not just one mailbox.
• No terms, no privacy links. “The publisher has not provided links to their terms for you to review.” A legitimate business app almost always provides these.

The page is real Microsoft infrastructure. That is the whole point, and it is why URL inspection and “check the sender” advice fall short here.

Why OAuth consent phishing is so dangerous

Traditional phishing steals a username and password. OAuth consent phishing steals authorization, and that changes what the attacker can do. Think of it like a hotel key card that keeps opening the door even after the front desk changes your room password; cancelling the card is a separate step that nobody remembers to take. When the victim approves the app, the identity provider hands it an access token and a refresh token that already represent an authenticated session. From there, a single approval gives the attacker several advantages at once:

• No credential is ever captured. The victim never types a password into a fake page, so credential-based detection and password hygiene simply do not apply.
• MFA is never challenged. The token already represents an MFA-satisfied session, so there is no second login for MFA to protect. This is one reason the technique is so effective, but it is only one piece of the picture.
• Access survives password resets. Refresh tokens keep working after the victim changes their password, so standard incident response does not cut off the attacker.
• Data flows through official APIs. The attacker reads email, files, and contacts through Microsoft Graph, the Gmail API, or the Salesforce API, which looks like normal application traffic.
• Persistence by design. The malicious app keeps its access until an administrator finds and revokes the consent, which can take weeks.
• Tenant-wide blast radius. If an administrator approves “on behalf of your organisation,” the app gains access across the entire tenant, not just one mailbox.

This is part of a broader shift in attacker behavior. In the 2026 Verizon Data Breach Investigations Report, stolen credentials as an initial access vector fell to 13%, down from 22% the year before, while the human element remained present in 62% of breaches. Attackers are moving away from grabbing passwords and toward abusing authorization and trust, which is exactly what consent phishing does. For most organizations the practical impact is mailbox and file access, and a compromised mailbox is the usual launchpad for invoice fraud and business email compromise.

Source: Verizon 2026 Data Breach Investigations Report, p. 12 (human element, 62%) and p. 15 (stolen credentials, 13%).

How it compares to other phishing

• Steals your password? Classic credential phishing: yes. AiTM phishing: yes, proxied. OAuth consent phishing: no.
• Bypasses MFA? Classic credential phishing: no. AiTM phishing: yes, it steals a live session. OAuth consent phishing: yes, no login is needed.
• Survives a password reset? Classic credential phishing: no. AiTM phishing: no, the session is revoked. OAuth consent phishing: yes, through the refresh token.
• What the attacker gets. Classic credential phishing: credentials. AiTM phishing: a live session. OAuth consent phishing: a durable API token.
• How you stop it. Classic credential phishing: reset the password and enforce MFA. AiTM phishing: revoke sessions and reset. OAuth consent phishing: an administrator revokes the app consent.

OAuth device code phishing: the token-stealing variant

Device code phishing is the fastest-growing form of OAuth token theft, and it deserves special attention because it may never show a permissions screen at all.

The OAuth device authorization flow was built for input-limited devices such as smart TVs and command-line tools: the device displays a short code, and you enter it in a normal browser to authorize it. In a device code phishing attack, the attacker starts that flow and then sends you the code with an urgent pretext, for example “enter this code to verify your account.” You type it into Microsoft’s real device-authorization page and approve, and the resulting token goes to the attacker instead of a device you own.

The outcome is identical to a malicious-app consent grant: valid access and refresh tokens, no password captured, and MFA already satisfied. This is the mechanism behind several of the 2026 campaigns below.

Real OAuth consent phishing attacks in 2025 and 2026

This is no longer theoretical. Several high-profile campaigns in the last year relied on OAuth consent and device code abuse.

ShinyHunters vs. Salesforce (mid-2025 to mid-2026). Attackers used voice phishing to talk employees into authorizing an attacker-controlled connected app inside their Salesforce tenant, often disguised as the legitimate “Salesforce Data Loader” tool. Once approved, the app inherited the user’s permissions and made API calls to exfiltrate CRM data without re-authenticating, neutralizing MFA. Microsoft mapped a full year of this activity. Sources: Microsoft Security Blog, July 2026; The Hacker News.

Tycoon 2FA adopts device code phishing (April 2026). After a March 2026 takedown attempt, operators of the Tycoon 2FA phishing-as-a-service kit adapted it to run OAuth device authorization grant phishing against Microsoft 365. By impersonating the first-party “Microsoft Authentication Broker” client, a single successful consent yielded working tokens across Exchange Online, Microsoft Graph, and OneDrive. Source: eSentire Threat Response Unit.

Device code campaigns targeting government and academia (late 2025). Security researchers tracked multiple clusters, including a financially motivated actor (TA2723) and a suspected Russia-aligned actor (UNK_AcademicFlare), using device code phishing with compromised government and military accounts to build rapport before sending OneDrive-spoofing links. Source: public threat research, late 2025.

OAuth redirection abuse (March 2026). Microsoft detailed campaigns abusing OAuth redirect URI handling to deliver phishing pages and malware while riding legitimate authentication flows. Source: Microsoft Security Blog.

CoPhish abuses Microsoft Copilot Studio (October 2025). Researchers at Datadog Security Labs showed that a Copilot Studio agent’s login button can be pointed at a malicious app and configured to forward the resulting OAuth token to an attacker-controlled URL. Because the flow runs on Microsoft’s own domains and IP addresses, the token theft does not even appear in the victim’s web traffic. Source: Datadog Security Labs.

The common thread: every one of these worked because a human approved something, not because a firewall failed.

A word from Keepnet

“For years we told people to protect their passwords. OAuth consent phishing sidesteps that advice completely. The victim never types a credential. They simply click Accept, and the attacker leaves with a token that outlives every password reset and MFA prompt. That is why we build these consent screens directly into our simulations. People cannot recognize an attack they have never been shown.”

Ozan Ucar, Founder and CEO of Keepnet

How to detect OAuth consent phishing

Detection lives mostly on the administrator side, because the user-facing flow looks legitimate. In MITRE ATT&CK terms this maps to T1528 (Steal Application Access Token), commonly described as an illicit consent grant.

• Audit OAuth app grants and enterprise applications. In Microsoft Entra ID, open Enterprise applications, sort by newest, and review each app’s permissions and publisher. In Google Workspace, check Security, then API controls, then App access control. Watch for unverified publishers, generic names, and broad scopes like Mail.Read, Files.ReadWrite.All, or offline_access.
• Alert on new service principals and consent events. Sudden consent grants, especially admin consent, or a spike of API calls from a newly authorized app are strong signals.
• Use app governance and anomaly detection. Microsoft Defender for Cloud Apps and equivalent SaaS security tools flag risky OAuth apps and unusual token activity.
• Hunt for the offline_access scope on apps that have no business reason for persistent access.

How to prevent OAuth consent phishing

Prevention combines platform controls with human-layer defense. You need both.

Platform and admin controls

• Restrict user consent. Since July 2025, Microsoft’s managed consent policy is on by default for new tenants, so users cannot consent to third-party apps accessing organizational data without admin approval. Confirm it is enabled and consider the strictest setting, admin consent for all apps.
• Turn on the admin consent workflow so users can request an app and an administrator reviews it, instead of approving it themselves.
• Enforce publisher verification and block or limit unverified apps.
• Apply least privilege to any app you do approve, and set token lifetime and conditional access policies.
• Revoke aggressively. When you find a malicious grant, remove the app and revoke its refresh tokens; a password reset alone will not stop it.

Human-layer defense

Because the attack ends with a person clicking Accept, awareness is not optional. Teams need to see a consent-phishing prompt before they meet one for real.

This is where simulation matters. The Keepnet AI Phishing Simulator can run realistic OAuth consent phishing scenarios, like the example above, across email and other channels, then deliver adaptive security awareness training to anyone who approves the app. It turns an invisible, token-based threat into a teachable moment, and it reports who is at risk so you can focus training where it counts.

The gap is real. Gartner notes that 84% of security leaders track training completion as a top metric, yet the human element still appears in 62% of breaches. Completion is not the same as behavior change. Showing people the exact screen an attacker will use, and measuring how they respond, is what closes the gap.

Source: Gartner, “6 Ways to Transform Your Cybersecurity Awareness Program” (G00840741, March 2026), 2025 Secure Behavior Strategies Survey (n=65); Verizon 2026 Data Breach Investigations Report, p. 12.

How Keepnet safely simulates OAuth consent phishing

Because the attack ends with a person clicking Accept, the most reliable defense is letting employees meet the exact prompt in a safe setting. The Keepnet AI Phishing Simulator runs OAuth consent phishing as a controlled exercise that mirrors the real technique end to end, then turns a failed click into training.

Here is what makes the simulation both realistic and safe:

• It uses the real consent flow. The employee lands on the genuine Microsoft sign-in and consent screen, exactly as they would in a live attack, so the test reflects real decision-making rather than an obvious fake.
• The decoy app requests only inert permissions. It asks for harmless identity scopes (openid, profile, email, User.Read) and never requests a password or access to real data.
• Tokens are never stored. Only the identity claim is read and then immediately discarded. The signal of a failed test is the act of granting consent, not any stolen token or data.
• The debrief teaches remediation. The moment an employee approves, they see a just-in-time explanation that this was a training exercise, and they are shown how to remove the app themselves at myaccount.microsoft.com/consent. Recognizing the attack and knowing how to revoke access are both part of the lesson.

Because the technical mechanism is identical across scenarios, the same flow can carry many different pretexts. Three examples:

• Document Access. A shared-document review request, for example “the finance team needs you to review the Q3 budget file,” with an Open document button. This tests the everyday-workflow pretext.
• DocuSign Connect. An e-signature request, for example “a new supplier contract is waiting for your signature.” This tests urgency around a business process.
• IT Security Verification. A fake security alert, for example “unusual sign-in detected, verify to protect your access.” This tests fear and urgency, and it is the scenario shown in the screenshot above.

The pretext and app name change, but the underlying consent-grant technique stays the same. That is how one exercise library can cover a wide range of real attacker angles.

Ready to test your team? Run an OAuth consent phishing simulation with the Keepnet AI Phishing Simulator and turn your riskiest click into a teachable moment. Book a demo.

Related reading

• What is AiTM Phishing and how is it used in BEC
• Covert Redirect Attacks and how to protect against them
• Gmail Account Takeover: how attackers gain access