OAuth consent phishing tricks a user into authorizing a malicious or compromised application to access data through legitimate APIs. The user may authenticate on the real provider and complete MFA correctly. The dangerous step is granting permissions such as reading mail, accessing files, or maintaining offline access.
How the attack works
The victim receives a link to a document, application, or sign-in workflow. The identity provider displays a real consent screen. If the victim approves, the application receives tokens for the granted scope. The attacker may never learn the password.
Persistence can survive a password change because the application grant or refresh token remains valid.
Warning signs
Look closely at the application name, publisher verification, requested permissions, and why the application needs them. A simple document viewer should not require mailbox access, directory data, or permission to act while you are offline.
Organizational controls
Restrict user consent to low-risk verified applications, require administrator review for sensitive scopes, inventory enterprise applications, expire unused grants, and alert on new high-impact consent. Review service principals and application credentials, not only human accounts.
Provide a fast process for legitimate integrations. If approval takes months, users will search for shortcuts.
Response
Revoke the malicious grant and its tokens, identify every consenting user, inspect data access and mailbox activity, remove persistence, and investigate how the link arrived. Reset credentials when other evidence indicates compromise, but do not treat that as the complete fix.
The bottom line
OAuth can delegate access safely, but a genuine consent screen is not evidence that the application is trustworthy. Review what the app can do, who published it, and whether the permission matches the task.
