What is OAuth phishing?
OAuth consent phishing is a type of phishing attack where the threat actor's goal is to trick the user into granting a malicious OAuth application access through a legitimate, trusted identity provider’s authorization flow.
Once the user has approved the malicious application's consent request, the attacker can use the granted permissions to make API calls on the user's behalf. In many cases, the attacker also receives a refresh token, allowing them to continuously obtain new access tokens even after the original access token expires.
Device code phishing is a variant that abuses the OAuth 2.0 Device Authorization Grant. It often reduces scrutiny because the user is focused on entering a short code at a trusted URL, and may not carefully review which app is being authorized or what scopes it requests.
What OAuth phishing is not
Unlike traditional phishing, OAuth phishing does not steal credentials or depend on fake sign-in pages. MFA often doesn’t save you here, as the attacker never has to defeat MFA directly. Access is granted when the user approves a malicious application through a legitimate authorization flow. Mitigations include restricting user consent, and where feasible, blocking device code flow via Conditional Access.
How does OAuth consent phishing work?
OAuth consent phishing usually begins just like any other phishing attack. The user receives an email designed to provoke feelings like curiosity, urgency, fear, or trust. The email contains a link that appears legitimate.
The user clicks the link, and instead of being taken to a suspicious-looking domain, they are taken to a legitimate Microsoft or Google sign-in page. This greatly increases trust because everything seems normal and secure.
After signing in, the user is shown a consent screen asking them to authorize an application. If they approve, the malicious application receives tokens, which grant ongoing API-level access. From here, the authorized malicious application can read emails, send messages, access files, or perform other actions on behalf of the user depending on the scopes it requested. Multi-factor Authentication often does not prevent this attack because the user completes MFA during a legitimate sign-in, after which the OAuth consent grants persistent access without further MFA prompts.
Common OAuth consent phishing scenario
A typical OAuth consent phishing scenario follows this pattern:
- The attacker registers a seemingly legitimate app (e.g., “Secure Document Viewer”).
- The user receives a phishing email that includes a link to authorize the app, potentially disguised as something entirely different.
- The user signs into a real Microsoft/Google page.
- The user is presented with a consent screen that requests access such as:
- Read email
- Send mail as user
- Access files in OneDrive/Drive
- Maintain access offline
- The user clicks “Accept.”
- The attacker receives tokens and gains ongoing access without the user ever noticing.
What the attacker can do next: read emails, send messages, access files, or perform other actions on behalf of the user, depending on the scopes requested by the malicious application.
Device code phishing: a variant of OAuth abuse
Device code phishing is a form of OAuth phishing that abuses the OAuth 2.0 Device Authorization Grant, a flow originally designed for devices with limited input capabilities, such as smart TVs and printers. Rather than using a traditional browser redirect back to the application, device code flow has the user authenticate on a separate verification page using a short code. Consent prompts may still appear, but the ‘enter this code’ step often draws attention away from the app identity and scopes.
In a device code phishing attack, the threat actor initiates an OAuth device authorization request and receives a device code and verification URL from a legitimate identity provider. The user is then socially engineered to visit the real device verification page and enter the provided code. As before, because the user is authenticating directly with a trusted domain, the process appears legitimate and may not raise any alarms. Behind the scenes, the attacker’s client polls the token endpoint and receives tokens as soon as the user completes verification and authentication.
Once that happens, the attacker-controlled application can obtain an access token, granting API-level access. Depending on the environment, the user may see less context, or pay less attention to which application is being authorized and what permissions are being granted compared to a typical consent flow. As with standard OAuth phishing, no login credentials are stolen. MFA often doesn’t prevent the compromise because the user completes MFA during a legitimate sign-in, then unknowingly authorizes the application. This reduced visibility makes it harder for users to recognize that they are granting ongoing access to an application at all.
Common device code phishing scenario
Device Code phishing begins like a traditional phishing attack. The user receives a phishing email containing a social engineering lure crafted to appear legitimate and relevant, and includes a link controlled by the attacker.
Clicking the link takes the user to a malicious website, prompting the user to sign in with their email address. Behind the scenes, the attacker has already initiated an OAuth 2.0 Device Authorization Grant request with Microsoft for a malicious application they control. This generates a legitimate device code tied to the attacker’s application.
After entering just their email address, the user is prompted to complete “secure authentication”. The user is presented with instructions to copy an “authorization code” and to proceed to Microsoft Authenticator.
In reality, this code is not an MFA challenge, instead it is the device code generated as part of Microsoft’s OAuth 2.0 Device Authorization Grant Flow that the threat actor had requested.
Following the Microsoft Authenticator link, the user is taken to a legitimate Microsoft website. However, instead of being taken to a MFA page, the user is directed to a device authentication page. If the user had already signed in on their Microsoft account, entering the code authorizes the malicious application and grants API-level access to the user’s Microsoft account. If the user was not signed in to their Microsoft account, they are prompted to sign in and complete MFA.
Why is OAuth phishing dangerous?
OAuth Phishing is particularly dangerous because the tokens that the threat actor receives remain valid independently of MFA enforcement. Since OAuth access is granted after a legitimate authentication event, the attacker does not need to defeat multi-factor protections themselves and can operate without triggering additional MFA challenges.
What makes matters worse, this authorization and token-based access can persist until the user or administrator explicitly revokes it, often granting the threat actor access for weeks or even months.
User behavior further increases the risk. Many users rarely read or fully understand permission scopes and will often approve access without realizing the extent of control they are granting. This makes it easy for malicious applications to request permissions that far exceed what is necessary.
Detection is also more challenging. API-based activity often lacks the indicators security teams rely on for traditional compromise detection, such as interactive logins or anomalous authentication patterns. As a result, OAuth abuse can persist undetected for extended periods, leading to effective account compromise and significant business impact
Defending against OAuth phishing
User level
Effective protection always starts with user awareness. Users should understand that OAuth can be weaponized just as easily as fake login pages. Training should focus on helping users recognize that approving an application deserves the same scrutiny as entering credentials, especially when the app or its permissions feel out of place. If someone asks you to enter a code at a trusted Microsoft URL, treat it like approving application access. Verify the application name and the requested permissions, otherwise do not proceed.
Even when the login page is legitimate, a suspicious consent prompt should be treated as a red flag and reported immediately.
Technical controls
Strong administrative policies can drastically reduce exposure. Limit or disable user consent to OAuth applications, and require admin approval for new consent requests, especially for apps requesting high-impact scopes. Restricting or blocking unverified OAuth applications prevents most malicious apps from being authorized in the first place. Require publisher verification where possible to reduce impersonation and look-alike apps.
Administrators should continuously monitor OAuth activity through tools like Azure AD Enterprise Apps or Google Workspace App Access Control, and routinely review and revoke unnecessary or stale OAuth tokens to limit long-term risk. Block or restrict device code flow via Conditional Access if your organization does not need it.
Detection strategies
Detecting OAuth-based attacks relies on identifying subtle anomalies. Signs of a malicious OAuth grant often show up as unusual API activity or the introduction of enterprise apps that users and administrators do not recognize. Alert on new OAuth app consents / newly added enterprise apps, especially when followed by unusual API activity.
Monitoring for these patterns and alerting on deviations from normal user activity helps surface OAuth phishing incidents that might otherwise go unnoticed. Combined with user awareness and strong technical controls, these detection efforts create a strong defense against OAuth phishing.
Key takeaways
OAuth phishing tricks users into authorizing a malicious OAuth application through a legitimate Microsoft or Google login flow. Instead of stealing passwords, the attacker gets API access via the permissions the user grants, which can allow various actions such as reading email and sending messages depending on the permission scopes, often without triggering further MFA prompts. A common variant, device code phishing, socially engineers users to enter a short code on a real login page, which can reduce visibility into what access is being granted. Effective defenses against OAuth phishing starts with raising user awareness, limiting user consent, requiring admin approval for new apps, and monitoring for suspicious new OAuth grants and unusual API activity.
Get more cybersecurity insights like this
- Subscribe to All Things Human Risk to get a monthly round up of our latest content
- Request a demo for a customized walkthrough of Hoxhunt
