# OAuth consent and device code phishing

Attacker-registered or attacker-initiated OAuth flows that bind a token or grant to the wrong party

_Area: Web authentication and account takeover. Seen in 3 disclosed reports; latest 2026-02-18. Updated 2026-10-23._

## How it works
OAuth separates who authorizes access from who receives the resulting token or grant. Consent phishing exploits this: a victim approves a legitimate-looking app, and the attacker's registered app receives a persistent grant. Device code phishing exploits the same split: the attacker starts the flow, the victim completes authorization in their own session, and the token lands with the attacker's polling client. In both cases the victim did authenticate correctly; the assumption that breaks is that the party authorizing is the party receiving access.

## Where it shows up
- OAuth apps with unverified publishers, missing homepage, or reply URLs on shared/free hosts (ClickFunnels, workers.dev, beehiiv) [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md)
- App names/logos using homoglyphs to impersonate Adobe, DocuSign, Microsoft [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md)
- Apps consented by only 1-2 users, low prevalence across the tenant [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md)
- Device code flow enabled on a tenant; authorization completed from a different client than the one that initiated it [E3](https://bugbountylibrary.com/r/blog%3Aembracethered-com-blog-posts-2022-device-code-phishing.md)
- Truncated links in messaging UIs where the visible prefix hides the true redirect destination [E2](https://bugbountylibrary.com/r/h1%3A643274.md)
- Redirect chains that log the user out of an identity provider before landing on an OAuth authorization prompt [E2](https://bugbountylibrary.com/r/h1%3A643274.md)

## How to review
Check the invariant: the principal that receives the token or grant must be the same principal that authorized it, and the user must be able to see the true destination and requesting app identity before consenting. Concretely: does the consent screen show verified publisher and real reply URL? Is device code flow needed, and can initiation and authorization be correlated to one client? Does the messaging UI reveal full URLs or only a trusted-looking prefix? For each app, compare metadata against the legitimate app it claims to be.

## Variants seen
- Malicious multi-tenant app with spoofed branding gaining persistent mail/file access [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md)
- Truncated DM link chaining logout, credential phishing, and OAuth app install, spreading virally [E2](https://bugbountylibrary.com/r/h1%3A643274.md)
- Device code flow where attacker initiates and victim authorizes, yielding a Graph API token [E3](https://bugbountylibrary.com/r/blog%3Aembracethered-com-blog-posts-2022-device-code-phishing.md)

## Impact and severity
High: persistent access surviving password resets and MFA [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md), account hijack with viral spread [E2](https://bugbountylibrary.com/r/h1%3A643274.md), and Graph API token theft [E3](https://bugbountylibrary.com/r/blog%3Aembracethered-com-blog-posts-2022-device-code-phishing.md). Severity rises with broad scopes, multi-tenant apps, and flows where the victim never sees the true requesting party.

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md
- E2: https://bugbountylibrary.com/r/h1%3A643274.md
- E3: https://bugbountylibrary.com/r/blog%3Aembracethered-com-blog-posts-2022-device-code-phishing.md