TL;DR: OAuth consent phishing bypasses MFA by abusing legitimate Microsoft and Google authorization flows for delegated access, according to Hoxhunt. Consent governance, token review, and app verification matter more than login strength once users can approve broad scopes.
Editorial analysis by NHI Mgmt Group, based on content published by Hoxhunt: “OAuth Consent Phishing: Why It’s Rising & How Awareness Programs Stop It”.
Key questions
Q: Why do malicious OAuth apps still work even when organisations use MFA?
A: They work because the attack targets the authentication session, not just the password.
Q: What are the warning signs that OAuth consent is being abused?
A: Warning signs include unexpected app registrations, broad scopes that do not match user role, consent events from unmanaged devices, and access patterns that continue after the original user interaction.
Q: What breaks when users are allowed to approve OAuth apps freely?
A: When users can approve OAuth applications without tight governance, a single click can create long-lived delegated access to mail, files, chat, and APIs.
Practitioner guidance
- Limit user consent by default Require admin approval for new OAuth app grants, especially for scopes that can read mail, send messages, or access files.
- Restrict high-risk OAuth scopes Block unverified or look-alike applications and require publisher verification where it is available to reduce impersonation risk.
- Review and revoke stale tokens Continuously monitor enterprise app consent events and remove OAuth tokens that are unnecessary, unrecognised, or no longer justified.
Bottom line: OAuth consent phishing exploits legitimate authorisation flows, so the security failure sits in delegated access rather than password compromise.
Glossary terms: OAuth App Consent Phishing, Device code phishing, Delegated Access Token, Consent Governance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Consent is the real trust boundary: OAuth phishing succeeds because users are asked to authorise an application, not just prove who they are. That means the security decision moves from authentication to delegated access, and the programme has to govern app consent as a privileged action. The implication is that consent review, scope limitation, and app allowlisting are identity controls, not optional hygiene.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: When should organisations block device code flow entirely?
A: Organisations should block it wherever the business does not depend on it, especially for users who do not need CLI sign-in. If the flow is still essential for specific teams, use report-only testing first, then enforce with narrow exceptions so you do not break legitimate developer access.
👉 Read our full editorial: OAuth consent phishing is bypassing MFA through trusted login flows