Topic starter
07/03/2026 1:39 am
TL;DR: Consent phishing abuses OAuth authorization to obtain persistent access tokens without stealing passwords or triggering MFA, and researchers tracked campaigns affecting 900 tenants and 3,000 user accounts, according to Obsidian Security. The real control gap is authorization governance, not authentication strength, because token abuse can outlive password resets and hide inside trusted SaaS integrations.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “Consent Phishing: How OAuth Attacks Bypass MFA and Traditional Security Controls”.
By the numbers:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
- Five major OAuth attack kits drove half of all device-code phishing traffic during autumn 2025.
Key questions
Q: What breaks when users can grant OAuth consent to risky applications?
A: The control that breaks is the assumption that a valid login equals safe delegated access.
Q: What are the signs that consent phishing is being used to bypass MFA in a SaaS environment?
A: A common sign is an OAuth app suddenly requesting broad mailbox, file, or calendar permissions that do not match the user’s role or normal workflow.
Q: How do teams know whether OAuth token governance is actually working?
A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner.
Practitioner guidance
- Restrict user consent for high-risk OAuth scopes Require administrator approval for permissions such as Mail.Read, Files.ReadWrite.All, and Directory.Read.All, and review any scope that grants broad mailbox or file access.
- Monitor token behaviour continuously Alert on unusual API call volumes, suspicious user agents, anomalous IP addresses, and apps that access data outside their stated purpose.
- Limit trust in first-party and device-code flows Apply Conditional Access, device compliance, and role scoping to administrative tools such as Azure CLI and PowerShell, then reassess any default exemptions.
Bottom line: Consent phishing works because OAuth tokens can outlive the authentication event that created them, leaving a durable access path inside SaaS.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 4:29 pm
Authorization governance is the control plane consent phishing actually attacks. MFA strengthens identity proof at login, but it does not govern what an already authenticated user can delegate to a third-party app. That means app consent, scope approval, and token lifecycle are the decisive controls in SaaS, not just authentication depth. Practitioners should treat delegated authorization as a first-class governance surface.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: What should teams do immediately after discovering a malicious OAuth grant?
A: Revoke the app grant, invalidate refresh tokens, terminate active sessions, and review any mailbox or API actions already taken through the compromised scopes. If the app was backdoored into a workflow, remove the malicious integration and confirm no additional delegated access remains.
👉 Read our full editorial: Consent phishing bypasses MFA by abusing OAuth trust in SaaS