OAuth App Consent Phishing

Expanded Definition

OAuth app consent phishing is a consent-layer attack against identity platforms, where a malicious application presents itself as trustworthy and persuades a user to approve access to mail, files, profiles, or other scoped resources. The risk is not limited to password theft. Once consent is granted, the attacker may receive tokens, API access, or delegated permissions that persist until revoked.

Definitions vary across vendors when the malicious app also routes the victim into a credential capture page, because some teams classify that as phishing while others classify the overall campaign as OAuth abuse or token theft. In NHI and IAM practice, the term is best understood as a delegated-authorisation compromise that exploits user trust in the consent screen itself. It is closely related to application grants, third-party app risk, and overbroad permission scopes. The consent prompt may look routine, but the real security event is the expansion of access without direct credential compromise. For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls provides relevant access, monitoring, and authorization guidance for limiting and reviewing granted privileges.

The most common misapplication is treating consent screens as low-risk user interface events, which occurs when organisations do not review third-party app grants as security-relevant identity changes.

Examples and Use Cases

Implementing oauth consent governance rigorously often introduces user friction and administrative review overhead, requiring organisations to weigh faster app adoption against tighter control of delegated access.

• A user approves a fake document-signing app, and the attacker uses the granted mail and file scopes to search for invoices, reset links, or internal conversations.
• A malicious productivity add-on requests offline access, then retains token-based access long after the initial click, turning a single approval into persistent foothold.
• An employee installs a seemingly helpful AI assistant, but the app is actually designed to siphon messages, contacts, and metadata into an external tenant, similar to patterns discussed in the CoPhish OAuth Token Theft via Copilot Studio report.
• A third-party integration is allowed broad tenant-wide scopes, and a compromised vendor becomes a supply-chain entry point, as seen in the Klue OAuth Supply Chain Breach analysis.
• A security team reviews consent logs after suspicious API activity and discovers that the initial compromise came from an approved app rather than a password spray or MFA bypass.

These patterns are especially dangerous because the user is often the final approval point, while the real security decision is hidden inside the permission scope. The consent flow may feel familiar, but the grant can silently create a long-lived NHI relationship between the app and the tenant.

Why It Matters in NHI Security

OAuth app consent phishing matters because it turns legitimate identity infrastructure into an attack path. Once a user approves access, the resulting tokens, refresh tokens, or delegated permissions can outlive the original interaction and bypass many password-centric defenses. In NHI programs, that means the compromise is not just about a user account. It can create a machine-to-machine foothold that spreads into mail, storage, CRM, or workflow systems.

NHI Management Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% only partial visibility, which makes consent abuse difficult to detect early. That visibility gap is why consent review, app allowlisting, and permission minimisation need to be treated as core identity controls, not optional app hygiene. The same concern appears in cases such as the Salesloft OAuth token breach and the Microsoft OAuth Breach, where delegated access became an operational security problem rather than a simple user mistake.

Organisations typically encounter the full impact only after anomalous mail access, data exfiltration, or vendor misuse is discovered, at which point consent phishing becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when OAuth consent phishing bypasses MFA and passkeys?
• What breaks when OAuth consent phishing happens inside the browser instead of at login?
• What breaks when AI client access is governed only by per-app OAuth consent?
• What is the difference between a service account and an OAuth-connected app?