What is OAuth phishing?

What it is#

OAuth phishing (also called consent phishing or illicit consent grant) is an attack where an adversary registers a malicious OAuth application and tricks a victim into granting it permissions. Instead of stealing a password, the attacker obtains an OAuth token that provides persistent access to the victim's mailbox, files, contacts, or other cloud resources. The victim clicks "Allow" on a legitimate consent screen hosted by the real identity provider, Microsoft, Google, or another OAuth-compliant service, making the attack difficult to distinguish from normal app authorization.

Unlike traditional phishing that harvests credentials, OAuth phishing exploits the authorization layer itself.

How the consent flow is abused#

A typical attack follows this sequence:

1. The attacker registers an OAuth app with a trustworthy-sounding name like "Document Viewer" or "IT Security Scanner", a form of brand impersonation applied to the app ecosystem.
2. A phishing email or message links the victim to the identity provider's real authorization endpoint, pre-populated with the malicious app's client ID.
3. The victim sees a genuine consent screen, hosted on login.microsoftonline.com or accounts.google.com, and clicks Allow.
4. The identity provider issues an access token (and often a refresh token) to the attacker's app.
5. The attacker uses those tokens to read email, search files, or send messages as the victim.

Because the consent screen is hosted by the real provider, URL inspection and domain reputation filters rarely flag it. The attacker never sees the victim's password, and multi-factor authentication (MFA) is not triggered after the initial authentication.

Dangerous scopes and permissions#

The severity of an OAuth phishing attack depends on the scopes requested. Common dangerous scopes include Mail.Read, Mail.Send, Files.ReadWrite, and Contacts.Read. In Microsoft 365 environments, an attacker may also request application-level permissions that require tenant admin consent, granting access across the entire organization rather than a single user.

Google Workspace attacks typically request scopes like https://mail.google.com/ (full Gmail access) or https://www.googleapis.com/auth/drive (full Drive access). A single over-permissioned consent grant can expose years of stored data.

Detection signals#

• Unusual OAuth app registrations or consent events in Azure AD / Google Workspace audit logs
• Apps with high-privilege scopes (Mail.ReadWrite, Directory.ReadWrite.All) consented by non-admin users
• Consent events from IP addresses or locations inconsistent with the user's normal activity
• Apps with mismatched publisher domains or unverified publisher status
• Sudden spikes in token usage against mailbox or file APIs from a single application

Response and prevention#

When a malicious OAuth grant is confirmed, the immediate priority is revoking the app's tokens and removing the enterprise app registration. In Microsoft 365, this means revoking user consent and deleting the service principal. In Google Workspace, administrators revoke third-party app access from the admin console.

Preventive controls include restricting which apps users can consent to (requiring admin approval for sensitive scopes), disabling user consent entirely in high-security tenants, and deploying conditional access policies that block token issuance to unverified apps. Regular audits of consented applications help catch dormant grants before they're exploited.

OAuth phishing does not depend on lookalike domains or credential harvesting pages, so traditional anti-phishing controls like URL filtering and DMARC provide limited protection against it. This also differentiates it from adversary-in-the-middle phishing, which relies on proxy infrastructure and domain deception. That said, adversary-in-the-middle (AiTM) reverse proxies can also manipulate OAuth flows at the HTTP layer by rewriting parameters such as redirect_uri during the proxied authentication sequence, capturing session tokens rather than obtaining a persistent consent grant. The two techniques target different layers of the authorization stack (consent grants vs. session tokens) but both exploit the OAuth ecosystem. However, a successful OAuth consent grant can lead directly to email account compromise, giving the attacker persistent mailbox access that survives password resets.