## TL;DR
Consent phishing has no malicious link to scan: the URL is the real identity provider, and the user is tricked into granting a real OAuth app access to their mailbox or files. Link policy cannot help. The defence is consent governance: restrict who can consent to unverified apps, audit existing grants for over-scoped permissions, and revoke the campaign app tenant-wide.

```text
"consent phishing" oauth app grant slipped past link-scanning policy
```

## Use this when
- An unfamiliar app holds mailbox or file permissions for several users.
- A campaign asked staff to approve an app with a familiar-sounding name.

## Not for this skill when
- The app is a sanctioned business tool with expected scopes. Document and allow it through the approval workflow.
- Users typed passwords into a clone page. That is credential phishing, handled differently.

## Steps
1. List enterprise app grants with high-risk scopes such as mailbox read or offline access and sort by publisher verification and user count. Verify: suspicious grants are shortlisted.
2. For the suspect app, record publisher, scopes, first grant date and affected users. Verify: the blast radius is known before revocation.
3. Revoke the app consent tenant-wide and disable the service principal. Verify: the app no longer appears as grantable and existing sessions are cut.
4. Set user consent to disallow apps from unverified publishers, with an admin consent workflow for exceptions. Verify: a test grant of a new unverified app requires admin approval.
5. Review audit logs for actions taken through the app, such as new inbox rules, and remediate any found. Verify: downstream abuse from the grant is checked, not assumed absent.

## Variant phrasings
### consent phishing malicious oauth app revoke grants
The revocation variant.
### restrict user consent unverified apps admin workflow
The prevention variant.

Compatibility: Microsoft Entra ID consent framework and Google Workspace third party app access controls.

## Why it happens
The consent page is genuine, so every URL control sees a legitimate destination. What is malicious is the combination of a deceptive app name and broad scopes, which only grant auditing and consent policy can catch.

## Edge cases / pitfalls
- Offline access plus mail read is the classic data theft pairing. Alert on it for new apps.
- Admin consent workflow fails if approvals are rubber stamps. Require a business owner and scope justification.
- Attackers name apps to mimic add-ins staff know. Include app publisher, not just name, in user guidance.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SDwT2kyn9n8-xsq4OKIkbQ