As reported by Dark Reading, the cybersecurity community's reliance on MFA as a near-universal identity panacea has created a dangerous blind spot around OAuth consent abuse. The article correctly identifies a structural problem that many organisations still underestimate: consent phishing does not break authentication — it exploits the authorisation layer that sits beside it.
The Fundamental Disconnect
MFA validates who is signing in. OAuth consent grants define what an application can do once that identity is established. Consent abuse attacks — sometimes called "consent phishing" or "illicit consent grant" attacks — operate by convincing an authenticated user to grant a malicious application permissions to their data. The user authenticates with MFA, then willingly hands a third-party app access to their mailbox, files, or directory. From the platform's perspective, everything is working as designed.
This is not an authentication failure. It is an authorisation governance failure — and no amount of push notifications, hardware keys, or passkeys will close that gap.
Who Is Most Exposed
Environments with large Microsoft 365 or Google Workspace footprints are the primary targets, because both ecosystems support rich third-party app models with broad API scopes. Organisations at greatest risk typically share these characteristics:
Attackers use these grants for persistent access, token theft, and lateral movement. A compromised OAuth refresh token can outlive password resets and MFA re-enrolment, making revocation workflows critical.
Why This Matters Beyond the Individual User
A single user granting a malicious app mailbox read access can expose sensitive correspondence, internal documents, and password reset emails — effectively creating a backdoor that survives credential rotation. In regulated industries, this can also constitute a reportable breach under GDPR, HIPAA, or SEC disclosure rules, even if no credentials were technically "stolen."
The broader implication is that identity security programmes built solely around authentication hardening are incomplete. Authorisation governance — specifically consent, scopes, and delegated permissions — must be treated as a first-class security domain.
Shield53 Recommendations
Immediate Actions
- Restrict user consent — In Microsoft Entra ID, set consent policies so users can only consent to apps from verified publishers and for selected permissions. In Google Workspace, configure OAuth app allowlists or block external apps by default.
- Audit existing grants immediately — Export all OAuth consent grants and refresh tokens. Flag any app with
Mail.Read,Mail.ReadWrite,Files.Read.All, or directory-level scopes that is not on an approved list. - Revoke suspicious grants — Use Microsoft Graph or the Google Admin SDK to revoke tokens for unrecognised or non-business-essential applications.
Strategic Controls
- Deploy app governance — Microsoft Defender for Cloud Apps or equivalent CASB tooling provides continuous monitoring of OAuth app behaviour, anomaly detection, and automated revocation.
- Implement least-privilege scope reviews — Maintain an approved application catalogue with documented business justification for each scope requested.
- Build detection content — Alert on consent grants to apps with publisher status "unverified," apps requesting broad scopes from non-admin users, and spikes in consent activity.
- User education targeted at consent screens — Train users to recognise the difference between signing in and authorising an app. Phishing simulations should include consent-phishing scenarios, not just credential harvesters.
- Token lifecycle management — Enforce token expiration policies where possible and review refresh token lifetimes. Long-lived refresh tokens are the persistence mechanism that makes consent abuse so damaging.
Detection Signals to Prioritise
- New OAuth app consent events from non-admin accounts.
- Apps accessing mail APIs shortly after consent grant.
- Consent grants to applications with recently created or low-reputation domains.
- Refresh token usage patterns inconsistent with user login geography or device posture.
MFA remains essential. But treating it as sufficient for identity security is a category error. Authentication and authorisation are separate control planes — both require governance, monitoring, and response capability.
Consent abuse is not a new attack, but it remains under-defended because it falls between the cracks of identity teams, application security teams, and SOC monitoring. Closing that gap requires explicit ownership, policy enforcement, and detection content designed for the authorisation layer — not just the login screen.
