What is consent phishing?
By Identra · Updated
Consent phishing is a social engineering attack where an adversary registers a malicious OAuth application and tricks a user into granting it delegated permissions on a real consent screen. Instead of stealing a password, the attacker walks away with a valid API token that survives password resets and bypasses MFA.
Key numbers
- Nearly 3,000 user accounts across more than 900 Microsoft 365 environments were targeted by OAuth app impersonation campaigns in 2025 (Proofpoint, 2025)
- Account takeover success exceeded 50 percent when OAuth app lures were paired with attacker-in-the-middle phishing kits (Proofpoint, 2025)
- More than 50 impersonated applications were observed in a single campaign cluster, including fakes of Adobe, DocuSign, RingCentral, and SharePoint (Proofpoint, 2025)
How does a consent phishing attack work?
The attack starts with something completely legitimate: the OAuth authorization flow that every SaaS platform uses to let third-party apps act on a user's behalf. The attacker registers an application with the identity platform, gives it a trustworthy name and logo, often impersonating a known brand, and requests delegated scopes such as reading mail, accessing files, or maintaining access when the user is offline. Then they deliver a link, usually by email, that sends the victim to the platform's genuine consent screen.
This is the part that makes consent phishing so effective. The URL in the browser bar is the real identity provider. The page is not spoofed. The victim signs in normally, satisfies any MFA challenge, and sees a permission prompt that looks like a routine app authorization. One click on Accept and the platform issues the attacker's app an access token, and often a refresh token, scoped to whatever the victim approved. No credentials changed hands, yet the attacker now holds durable API access to the account.
Why does consent phishing bypass MFA?
Traditional phishing steals a secret, so defenses concentrate on protecting the secret: password policies, phishing-resistant MFA, impossible-travel detection on logins. Consent phishing sidesteps all of it because the victim performs a fully legitimate authentication. MFA is satisfied, the session is genuine, and the malicious grant is issued by the platform itself. From that point forward the attacker operates through API calls that carry a valid token, not through logins that identity monitoring watches.
The token also outlives the moment. OAuth grants typically survive password resets, and a refresh token can mint new access tokens for months or years. That persistence turns one click into standing access, which is why consent phishing is best understood as the attack-side twin of OAuth app risk: the same delegated-grant machinery that powers integrations becomes the breach, and the resulting foothold behaves like session hijacking that never expires on its own.
What do real consent phishing campaigns look like?
This is an industrialized technique, not a proof of concept. Proofpoint tracked campaigns through 2025 that used Microsoft OAuth app impersonation as the lure, observing more than 50 fake applications posing as brands such as Adobe, DocuSign, RingCentral, and SharePoint. Those campaigns targeted nearly 3,000 user accounts across more than 900 Microsoft 365 environments, and when the OAuth lure was chained with attacker-in-the-middle kits such as Tycoon, the confirmed account takeover rate exceeded 50 percent.
Attackers have also abused the trust signals meant to stop them. In early 2023 Microsoft investigated a campaign in which threat actors fraudulently obtained verified publisher status so their malicious apps carried the blue badge users are told to look for. The lesson for defenders is that no single consent-screen indicator is reliable: app name, logo, and even publisher verification can all be forged or gamed, so detection and response has to look at what grants exist and what they do, not what they claim to be.
How do you detect consent phishing?
Because the login is legitimate, detection has to move from the sign-in event to the grant and its aftermath. The core telemetry is the consent event itself: which app was authorized, by whom, with what scopes, and from what publisher. A brand-new app requesting broad mail or file scopes across multiple users in a short window is a strong signal, and most major platforms now expose audit events that make this visible.
- Alert on new consent grants, especially high-risk scopes such as full mailbox access, file read on all sites, or offline_access, and triage them like potential incidents
- Baseline the OAuth app population and flag first-seen apps, unverified publishers, and lookalike names that imitate known vendors
- Watch post-consent behavior: mass mail reads, inbox rule creation, bulk file downloads, and API activity from infrastructure the tenant has never seen
- Inventory existing grants regularly, because a posture review often finds malicious or abandoned apps that predate your alerting
How do you prevent consent phishing?
Prevention means shrinking who can grant consent and what a grant can contain. The single highest-leverage control is restricting user consent so that employees cannot unilaterally authorize unknown apps: platforms support admin consent workflows where risky requests route to a reviewer instead of being one click away. Microsoft moved this direction platform-wide, announcing in mid-2025 that Microsoft 365 tenants would require admin consent for third-party app access to files and sites by default, with the change rolling out to all tenants from July 2025.
Beyond the consent gate, the durable fix is treating every OAuth grant as a non-human identity with an owner, a scope budget, and a lifecycle. Grants should follow least privilege, get reviewed on a schedule, and be revoked when the app goes unused, because revocation is the only way to end access once a token is issued. User education still matters, but the consent screen is designed to make approval easy, so architecture, not awareness, has to carry the weight.
How Identra thinks about it
Consent phishing is what happens when an attacker weaponizes the fact that most organizations govern logins but not grants. Every Accept click mints a non-human identity with API access that no MFA policy will ever challenge again, and in most environments nobody owns that inventory. Identra's view is that the consent event is an identity lifecycle event: every OAuth grant, whether approved by a user, an admin, or an AI agent wiring up its own tools, should be discovered, attributed to an owner, scoped to least privilege, and monitored at runtime for behavior that does not match its purpose. Catch the malicious grant as it is born, not months later in an audit.
Go deeper: The Non-Human Majority
Frequently asked questions
How is consent phishing different from credential phishing?
Credential phishing steals a secret, usually a password or a one-time code, on a fake page. Consent phishing uses the real identity provider's consent screen and steals authorization instead: the victim grants a malicious app delegated permissions, and the attacker receives a valid OAuth token without ever seeing the password.
Does MFA stop consent phishing?
No. The victim completes a legitimate login, including MFA, before approving the malicious app. The attacker then operates through the granted token, which is not challenged by MFA. Stopping the attack requires controls on consent itself, such as admin consent workflows and grant monitoring.
How do you remove a malicious OAuth grant?
Revoke the application's grant and refresh tokens in the identity platform, then review audit logs for what the app accessed while authorized. Resetting the user's password is not sufficient, because OAuth tokens generally survive password changes. Follow up by restricting user consent so the same app cannot be re-approved.
Can a verified publisher badge be trusted on a consent screen?
Not on its own. Microsoft investigated a 2023 campaign in which attackers fraudulently obtained verified publisher status for malicious apps. Publisher verification raises the bar, but review the requested scopes and the business justification before approving any app, badged or not.