Consent Phishing and Illicit OAuth Grants Guide: Controlling App Consent

Consent phishing tricks a user into granting a malicious application OAuth access to their data, and that grant survives password resets and MFA because the attacker never needed the password. This guide explains how illicit consent grants work, where they appear across Microsoft Entra ID, Google Workspace and SaaS platforms such as Salesforce, how to detect and remove them, and which consent settings stop most of them. It is written for identity, SaaS security and SOC teams. Platform configuration of Entra enterprise applications is covered in depth in the Entra ID Applications and Consent Guide, and broader app inventory and lifecycle in the SaaS and OAuth App Governance Guide; this page covers the attack and the controls that break it.

Key takeaways

• The grant is the foothold. Once a user consents, the application holds tokens that work without the user's password or MFA, so resetting the password does not remove access.
• Default consent settings are the root cause. In Entra ID, by default all users can consent to permissions that do not require administrator consent; restricting user consent to verified publishers and low-impact permissions removes most of the attack surface.
• An admin consent workflow is the price of restriction. Blocking user consent without a request path pushes users to shadow workarounds; give them a reviewed route instead.
• Detection starts with one audit event. In Microsoft 365 the activity is "Consent to application"; watch IsAdminConsent, ConsentType AllPrincipals and high-risk scopes such as mail and file access.
• Remediation means revoking grants, not just disabling the app. Remove the delegated permission grants and app role assignments, then block re-consent, or the same user can approve the app again.

How the attack works

OAuth lets a user delegate access to an application without sharing a password. Consent phishing abuses that delegation. Microsoft describes the pattern as an attacker registering an application that requests access to data such as contact information, email or documents, then tricking a user into granting consent through phishing or code injected into a trusted website. Password resets and MFA do not stop it, because the application is external to the organisation.

• Lure: an email, chat message, document share or phone call that gives the user a reason to click "Accept", for example a policy violation notice, a shared file or an "IT support" request.
• Consent screen: the user lands on the real identity provider sign-in and consent page. Nothing in the URL bar looks wrong.
• Scopes: the application asks for delegated permissions such as reading mail, files or contacts, and often offline access so it receives a refresh token.
• Token use: the attacker calls APIs directly with the tokens, so no risky interactive sign-in occurs.

In MITRE ATT&CK terms the lure is Spearphishing Link (T1566.002), obtaining the token maps to Steal Application Access Token (T1528), and using it against cloud APIs maps to Use Alternate Authentication Material: Application Access Token (T1550.001). Where an attacker with admin rights grants an application broad permissions to keep access, see Additional Cloud Roles (T1098.003).

Consent phishing compared with related attacks

See the AiTM Phishing Guide and the Device Code Phishing Guide for those variants.

Where it shows up

• Microsoft Entra ID and Microsoft 365: multitenant applications registered in an attacker's tenant request Microsoft Graph delegated permissions. The grant appears as an enterprise application (service principal) with delegated permission grants in the victim tenant.
• Google Workspace: third-party OAuth apps request Gmail, Drive or other Google API scopes. Unless the admin has configured API controls, users can grant access to any third-party app, which is the default.
• Salesforce and other SaaS: connected apps authorised by a user. The ShinyHunters campaign showed that the lure need not be email: callers posing as IT support talked staff through authorising a modified copy of Data Loader.
• Developer platforms: OAuth apps on GitHub, browser extension stores and similar platforms, where a single grant can carry publishing or repository rights.
• AI tools and assistants: employees connecting consumer AI products to corporate mail, calendar and files. This creates the same kind of long-lived grant. See the Shadow AI Discovery Guide.

Impact

• Data access without sign-ins: mail, files and CRM records are read through APIs, often in bulk.
• Persistence: refresh tokens let the app keep working for weeks or months, and the grant outlives the user's password changes.
• Lateral reach: mailbox access exposes reset links and internal threads; a publishing grant turns one user into a supply chain path.
• Tenant-wide exposure: if an administrator consents on behalf of the organisation, the grant covers every user's data, not just one account.

Detection

What to log and where

• Latency: Microsoft notes that audit entries can take between 30 minutes and 24 hours to appear, so real-time alerting needs the audit stream fed into a SIEM rather than manual searches. See the SIEM Guide.
• Inventory: export every OAuth grant regularly. Microsoft's investigation guidance suggests a weekly review of consent grants for large tenants.
• Red flags in app metadata: misspelled or generic names, no verified publisher, a reply URL on an unrelated domain, an app registered recently, and scopes that do not match the stated purpose.
• Prerequisite: scoping an incident depends on mailbox auditing and activity auditing having been enabled before the attack.

Metrics that show the controls work

• Percentage of tenants or org units where user consent is restricted to verified publishers and low-impact permissions, or disabled (target: 100%).
• Number of third-party apps holding tenant-wide (AllPrincipals) grants, and the trend over time.
• Median time from "Consent to application" event to review for high-risk scopes.
• Median time to approve or deny admin consent requests (a long queue signals users will look for workarounds).
• Number of grants unused for 90 days still active.

Prevention and hardening

Microsoft Entra ID

• User consent settings: under Enterprise apps > Consent and permissions > User consent settings, either disable user consent or allow it only for apps from verified publishers, or apps registered in your own tenant, for permissions classified as low impact. The corresponding built-in policy is microsoft-user-default-low; avoid microsoft-user-default-legacy, which allows consent to any permission that does not require admin consent. Changes apply only to future consents, so existing grants must be reviewed separately.
• Permission classifications: decide which delegated permissions count as low impact (typically basic sign-in and profile). Keep mail, files and offline access out of that list.
• Admin consent workflow: under Admin consent settings, enable "Users can request admin consent to apps they are unable to consent to", name reviewers by group or role, turn on notifications and set an expiry. Only Global Administrators can approve requests for Microsoft Graph application permissions.
• Risk-based step-up consent: enabled by default, it forces admin consent for risky requests such as newly registered multitenant apps that are not publisher verified and ask for more than basic permissions. Keep it on (the setting is BlockUserConsentForRiskyApps).
• Publisher verification is a signal, not a guarantee: Microsoft states the verified badge does not imply quality criteria. Review requested permissions even for verified publishers; fraudulent partner accounts have been used to obtain the badge, as the Microsoft verified publisher OAuth phishing 2022 case showed.

Google Workspace

• API controls: under Security > Access and data control > API controls, change the setting for unconfigured third-party apps from the default (allow any app) to either allowing only apps that request basic sign-in information (name, email, profile picture) or blocking all third-party apps until they are configured.
• Access levels: mark reviewed apps Trusted, Limited or "Specific Google data" (only listed scopes), and block the rest.
• Restricted services and high-risk scopes: set Gmail and Drive to Restricted so only trusted apps reach them; switching a service to Restricted revokes tokens held by untrusted apps. Allow changes up to 24 hours to apply.

Salesforce and other SaaS

• Who can authorise apps: limit the permission to manage or authorise connected apps to a small admin group and allowlist approved apps, as Google's analysis of the ShinyHunters campaign recommended. See the Salesforce Security Guide.
• IP restrictions: restrict where integration tokens can be used from, so a stolen or illicit token is less useful outside expected networks.
• Help desk script: state that IT will never ask anyone to authorise an app or enter a connection code over the phone. See the Callback Phishing (TOAD) Guide.

Choosing a consent model

Small organisations without a review team should still move off "allow all": the verified-publisher model needs little upkeep.

Rollout

1. Baseline: export all current OAuth grants on each platform, flag tenant-wide grants and high-risk scopes, and identify owners.
2. Clean up: revoke grants that are unknown, unowned or unused; confirm with owners before removing business-critical integrations.
3. Enable the request path first: turn on the admin consent workflow (or Google's app access requests) and publish how users request an app.
4. Restrict consent in a pilot: apply the restricted setting to a pilot group or organisational unit for two to four weeks and track blocked requests.
5. Roll out tenant-wide and alert on every admin consent and every grant with high-risk scopes.
6. Roll back if needed by reassigning the previous consent policy; existing grants are unaffected either way.

Responding to an illicit grant

1. Identify the app, its client ID, the consenting users and the scopes held.
2. Revoke delegated grants (Remove-MgOauth2PermissionGrant) and application permission assignments (Remove-MgServicePrincipalAppRoleAssignment), or remove the app from the users' Applications view. Note that user consent grants cannot be revoked in the Entra portal; use Graph or PowerShell.
3. Block re-consent through consent settings, because revoking alone does not stop the user approving it again.
4. Check other authorisation systems the app may hold, such as Exchange RBAC and Teams resource-specific consent.
5. Scope the data accessed from audit logs for the period the app held access, and rotate any secrets found in that data.

Where Microsoft itself disables a malicious app, new token requests are denied but existing access tokens remain valid until they expire. See the OAuth Token Theft Incident Playbook and the Phishing Incident Response Playbook.

Framework mapping

Lessons from incidents

• A genuine consent screen can belong to a malicious app: in the Cyberhaven Chrome extension breach 2024, a fake Chrome Web Store policy email led an employee to Google's real consent screen for an app called "Privacy Policy Extension". The grant carried publishing rights, no MFA prompt appeared, and a poisoned extension reached about 400,000 users.
• The lure can be a phone call: in the ShinyHunters Salesforce data theft campaign 2025, callers posing as IT support had staff authorise a modified Data Loader, which then bulk-exported CRM records. Salesforce itself was not breached.
• Voluntary grants become illicit when the vendor is breached: in the Vercel Context.ai OAuth breach 2026, an employee had given a consumer AI app full access to a corporate Google account; after the vendor was compromised the token was used to take over the Workspace account.
• Know which problem you have: the Salesloft Drift breach 2025 was not consent phishing: tokens of an approved integration were stolen from the vendor. Consent controls do not help there; scope limits, IP restrictions and fast revocation do.

Common failure patterns

• Leaving the legacy "allow all apps" consent setting in place.
• Treating the verified publisher badge as approval.
• Reviewing only admin consents and missing per-user grants with mail or file scopes.
• Restricting consent without a staffed admin consent workflow, so users route around it.
• Resetting the user's password and closing the incident while the grant stays active.

Practitioner checklist

• Restrict user consent to verified publishers and low-impact permissions, or disable it, on every tenant.
• Enable and staff the admin consent workflow with a target approval time.
• Keep Entra risk-based step-up consent enabled.
• In Google Workspace, restrict unconfigured third-party apps and set Gmail and Drive to Restricted.
• Limit who can authorise connected apps in Salesforce and other SaaS platforms.
• Stream "Consent to application" and equivalent events to the SIEM and alert on admin consent and high-risk scopes.
• Export and review all OAuth grants at least monthly, weekly for large tenants.
• Confirm mailbox and activity auditing are enabled before you need them.
• Include grant revocation and re-consent blocking in the phishing response playbook.
• Train users and help desk staff that a real consent page can still be an attack.

Standards and references

• Microsoft Learn: Detect and remediate illicit consent grants
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Configure the admin consent workflow
• Microsoft Learn: Configure risk-based step-up consent
• Microsoft Learn: Review and revoke application permissions
• Google Workspace Admin Help: Control which third-party and internal apps access Google Workspace data
• IETF: RFC 9700 OAuth 2.0 Security Best Current Practice
• MITRE ATT&CK: Steal Application Access Token

Related NHI Mgmt Group resources: Entra ID Applications and Consent Guide · SaaS and OAuth App Governance Guide · OAuth 2.0 and OpenID Connect Guide · Microsoft 365 Security Guide · Top 10 Phishing Techniques