Consent Phishing vs Credential Phishing: OAuth grants that survive password resets

Credential phishing steals something the user knows, while consent phishing persuades the user to give an attacker's application a standing OAuth grant, and the two need different responses. Teams that treat every phishing click the same way reset the password, re-register MFA and close the ticket, which works for stolen credentials but leaves an illicit grant fully working. This guide compares the two attacks side by side: threat model, how each flows through the identity provider, why MFA and password resets help one and not the other, the preventive controls that matter for each, detection signals and response runbooks. It is written for identity, SaaS security, SOC and incident response teams. Platforms are listed alphabetically (Google Workspace, then Microsoft Entra ID); order is never a ranking. The attack itself is covered in depth in the Consent Phishing and Illicit OAuth Grants Guide; this page is the decision and response comparison.

Key takeaways

• Different asset, different fix. Credential phishing takes a password, an MFA response or a session cookie; consent phishing takes nothing from the user and instead creates a grant that lives in the tenant until someone removes it.
• Resets do not remove grants. Microsoft states that resetting passwords or requiring MFA is not effective against illicit consent grants because the malicious app is external to the organisation.
• Phishing-resistant MFA solves one problem only. FIDO2 and WebAuthn stop most credential and AiTM phishing, but a user who signs in with a passkey can still approve a malicious consent screen on the genuine identity provider.
• Consent policy is the consent phishing equivalent of MFA. Restricting user consent to verified publishers and low-impact permissions, with an admin request path, removes most of the attack surface.
• Triage must ask one extra question. On every phishing report, check for new application grants as well as sign-ins, because the remediation paths diverge at that point.

The short answer

Credential phishing is an attack on authentication. The attacker wants to become the user: sign in as them, from their own infrastructure, using a captured password, a relayed one-time code or a stolen session cookie. Consent phishing is an attack on authorisation. The attacker does not want to sign in as the user at all. They register an OAuth application, send the user to the real Google or Microsoft consent page and ask for delegated scopes such as reading mail or files. When the user clicks accept, the identity provider issues tokens to the attacker's application, and the application calls the APIs directly.

That single difference drives everything else. With credential phishing, the attacker's access depends on the user's authenticators and sessions, so changing them breaks the attack. With consent phishing, access depends on a grant object stored in the tenant, so only removing that grant (and stopping it being re-created) ends the attack. See the Top 10 Phishing Techniques for the wider family.

Side-by-side comparison

Threat models compared

Credential phishing

The attacker's goal is to replay the user's identity. CISA describes the basic pattern as email or malicious websites that mimic a login portal to capture usernames, passwords and one-time codes from authenticator apps, alongside push bombing (flooding a user with prompts until one is accepted) and SIM swapping to intercept text message codes. Adversary-in-the-middle kits go a step further and relay the full sign-in to the real provider, capturing the resulting session cookie so the MFA step is already satisfied. See the AiTM Phishing Guide.

• Attacker capability needed: phishing infrastructure, a convincing domain and, for AiTM, a reverse proxy kit.
• What limits the attacker: Conditional Access on device compliance, location and sign-in risk; token lifetimes; the user noticing an odd domain.

Consent phishing

The attacker's goal is a durable integration. Microsoft describes the 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, after which the app has account-level access without needing an organisational account.

• Attacker capability needed: an app registration in any tenant or developer console, a plausible name and logo, and a lure.
• What limits the attacker: the tenant's consent policy, publisher verification, which scopes require admin consent, and app allowlists.
• Typical follow-on: bulk reading of mail and files through the API, mail sending as the user, and, where the scope allows, publishing or repository rights. The Cyberhaven Chrome extension breach shows the extreme case: an employee approved a genuine Google consent screen for a malicious app with Chrome Web Store publishing rights, with no password or MFA prompt standing in the way.

How each attack flows through the identity provider

1. Lure: identical in both. A shared document, a policy notice, an invoice or a chat message with a link.
2. Landing page: credential phishing lands on attacker infrastructure that imitates or proxies the provider. Consent phishing lands on the provider itself, with an authorisation request naming the attacker's client ID, redirect URI and scopes.
3. Authentication: in credential phishing the user authenticates to the attacker, who relays or stores the result. In consent phishing the user authenticates to the real provider, so every policy you have (MFA, device compliance, location) is satisfied by the real user on their real device.
4. Decision point: credential phishing has none beyond the user typing a password. Consent phishing presents a consent screen. The tenant's consent policy decides whether the user is allowed to approve, must request admin approval, or is blocked.
5. Token issuance: in credential phishing tokens or cookies go to the user's session, which the attacker then hijacks. In consent phishing tokens go straight to the attacker's application. If the app asked for offline access it also receives a refresh token, so it can obtain new access tokens without the user present. RFC 9700, the OAuth 2.0 security best current practice, requires refresh tokens for public clients to be sender-constrained or rotated, but that protects tokens from theft; it does not help when the attacker is the legitimate client the token was issued to.
6. Use: the credential phisher appears as the user signing in. The consent phisher appears as an application calling Microsoft Graph or Google APIs on the user's behalf.

Step 4 is the control point that does not exist in credential phishing. It is where consent phishing is won or lost, and it is configured by an administrator, not decided by the user's vigilance.

Why MFA and password resets fail against consent grants

An OAuth delegated grant records that a user allowed an application to act for them with a given set of scopes. It is not tied to the user's password. Changing the password changes how the user proves identity in future; it does not withdraw a decision the user already made. Microsoft's illicit consent guidance says plainly that normal remediation steps such as resetting passwords or requiring MFA are not effective because the malicious apps are external to the organisation.

Session revocation helps more, but it is still not the fix. Microsoft documents that Revoke-MgUserSignInSession (Revoke sessions in the admin centre) revokes the user's Entra ID refresh tokens, and that access tokens last one hour by default, so access through an existing access token can continue until it expires. Even after tokens are invalidated, the grant object remains in the tenant, and Microsoft notes separately that revoking permissions does not stop a user re-consenting. Treat session revocation as a step that shortens exposure, and grant removal as the step that ends it.

The reverse is also true. Phishing-resistant MFA is the strongest control against credential phishing: CISA calls FIDO/WebAuthn the only widely available phishing-resistant authentication. Deploying it does nothing to the consent decision, because the user completes that phishing-resistant sign-in themselves before approving the app. See the Phishing-Resistant MFA Guide.

Prevention: controls that matter for each

Credential phishing controls

• Phishing-resistant MFA: FIDO2 security keys, platform passkeys or certificate-based authentication, starting with administrators and other high-value users as CISA recommends. Number matching is an interim step for push-based MFA.
• Conditional Access: require compliant or managed devices for sensitive apps, block legacy authentication, and use sign-in risk policies.
• Session and token controls: shorter sign-in frequency for high-risk apps, continuous access evaluation for capable apps, and token protection where supported.

Consent phishing controls

• Google Workspace: in API controls, set each known app to Trusted, Specific Google data, Limited or Blocked, and change the unconfigured third-party app setting from the default "Allow users to access any third-party apps" to "Allow sign-in only for apps requesting basic info" or "Don't allow users to access any third-party apps". Users can be allowed to request access to unconfigured apps, which then appear for review. See How to Inventory third party oauth apps in google workspace.
• Microsoft Entra ID: under Enterprise apps, Consent and permissions, User consent settings, move from the legacy setting (policy microsoft-user-default-legacy, where users can consent to any permission that does not need admin consent) to "Allow user consent for apps from verified publishers, for selected permissions" (microsoft-user-default-low), after classifying which permissions count as low impact. Enable the admin consent workflow so users can request the rest. See How to restrict user consent to apps in Entra ID and the Entra ID Applications and Consent Guide.
• Scope classification: define which scopes are high risk in your environment, typically full mail access, mail send, all files, directory read and write, and any offline access combined with those.
• App governance tooling: SaaS security posture or app governance products give an inventory of OAuth apps, which users granted them and what they can reach. Microsoft Defender for Cloud Apps app governance, for example, covers OAuth apps registered on Microsoft Entra ID, Google and Salesforce. See the SaaS and OAuth App Governance Guide.

Changes to consent policy apply only to future consent operations: Microsoft notes that existing grants remain in place. Every rollout must therefore include a one-off review of grants already held.

Decision guidance: which risk to fund first

Most organisations need both sets of controls, but the order depends on where they are today.

• Consent left at the default: fix this first. It is a configuration change measured in days, while phishing-resistant MFA is a programme measured in months. Until consent is restricted, every user can authorise any app for permissions that do not need admin consent.
• MFA based on SMS, voice or simple push: credential phishing and AiTM are the larger exposure. Start the phishing-resistant MFA rollout with administrators, help desk staff and executives while consent restriction proceeds in parallel.
• Small organisations: blocking user consent entirely with a simple admin request path is often workable, because the number of genuine app requests is low. Pair it with passkeys for every user.
• Large or developer-heavy organisations: full blocking generates request volume and shadow workarounds. Use the verified publisher and low-impact setting, a staffed admin consent queue with defined review criteria, and an allowlist of approved apps per business unit.

Detection signals compared

Microsoft notes that audit entries for consent can take between 30 minutes and 24 hours to appear in search, and recommends reviewing consent grants weekly in organisations with many apps and users. Build the consent detection as a scheduled analytics rule rather than relying on ad hoc searches.

Response runbooks side by side

Credential phishing

1. Reset the password and revoke sessions and refresh tokens; where the account is in a hybrid directory, follow the on-premises reset steps too.
2. Remove attacker-registered MFA methods and require re-registration with a phishing-resistant method.
3. Remove malicious inbox rules, forwarding and delegated mailbox access.
4. Review sign-ins and activity for the exposure window and hunt for internal phishing sent from the account.

See the Phishing Incident Response Playbook and the Session Token Theft Response Playbook.

Consent phishing

1. Identify the application: client ID, publisher, redirect URIs, scopes and the time of each consent.
2. Find every user who consented, not just the reporter, by grouping consent events and grants by application.
3. Remove the grants. In Microsoft Entra ID, delegated grants are removed with Remove-MgOauth2PermissionGrant and application permissions with the app role assignment cmdlets; Microsoft notes the admin centre cannot revoke user-consented permissions, so use Graph or PowerShell. In Google Workspace, set the app to Blocked, after which it cannot access any Google data.
4. Block re-consent: disable or block the app tenant-wide and tighten the consent policy if it allowed the grant.
5. Revoke affected users' sessions to cut off any access token still live, accepting the short window Microsoft documents for access tokens.
6. Scope the data accessed through the API for the full period the grant existed, which needs mailbox and activity auditing to have been enabled before the attack.

See the OAuth Token Theft Incident Playbook for the token side.

Worked scenario: one email, two outcomes

A finance team receives a message claiming a shared invoice is waiting. Two users click. The first lands on a proxied Microsoft sign-in page, enters a password and approves a push prompt; the kit captures the session cookie. The second lands on the real Microsoft sign-in page, signs in with a passkey and sees a consent screen for an app called "Invoice Viewer" asking to read mail and files and maintain access. They accept.

The SOC follows the credential runbook for both users: reset, revoke sessions, remove inbox rules. Two weeks later, data loss monitoring flags mail exports from the second user's mailbox, performed by an application, not a sign-in. The grant was never touched. The fix was a triage question on day one, "did this user grant any app access since the click?", and a tenant setting that would have sent "Invoice Viewer" to the admin consent queue instead of letting the user approve it.

Framework mapping

Common failure patterns

• One runbook for every phishing click: responders reset and close, and the consent grant stays live, as in the scenario above.
• Restricting consent without reviewing existing grants: the new policy only affects future consents, so grants approved last year keep working.
• Disabling the app for one user only: other users who consented keep the grant, and new users can still approve it unless the app is blocked tenant-wide.
• Assuming passkeys ended phishing: phishing-resistant MFA removes credential phishing risk but users still approve consent screens after a strong sign-in.
• Treating publishing and code scopes as ordinary: a grant that can publish an extension or push code turns one user's click into a supply chain incident, as the Cyberhaven Chrome extension breach showed.
• No audit baseline: without mailbox and activity auditing enabled beforehand, the team cannot say what an app read, which turns a contained incident into a notifiable one.

Detection and measurement

• Consent policy coverage: percentage of tenants and workspaces where user consent is restricted to verified publishers and low-impact scopes or blocked.
• High-risk grants outstanding: number of third-party apps holding mail, files or directory scopes, trending down after each review.
• Admin consent queue time: median days to decision; a long queue predicts workarounds.
• Phishing triage completeness: share of phishing incidents where the record shows both a sign-in review and an application grant review.
• Phishing-resistant MFA coverage: share of users, and of privileged users, who can only sign in with phishing-resistant methods.
• Time to grant removal: hours from first consent event to grant revoked for confirmed malicious apps.

Practitioner checklist

• Add "check new application grants since the click" to every phishing triage template.
• Move Entra ID user consent off the legacy setting and classify low-impact permissions.
• Change the Google Workspace unconfigured third-party app setting from the default.
• Enable and staff an admin consent request path with written review criteria.
• Run a one-off review of existing grants, prioritising AllPrincipals and mail, file and offline access scopes.
• Build scheduled detections for consent events and for apps reading data with no interactive sign-in.
• Roll out phishing-resistant MFA, starting with administrators and help desk staff.
• Keep separate, tested runbooks for credential theft and illicit consent, and practise both.

Standards and references

• Microsoft Learn: Detect and remediate illicit consent grants
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• Google Workspace Admin Help: Control which apps access Google Workspace data
• CISA: Implementing Phishing-Resistant MFA
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• MITRE ATT&CK: T1528 Steal Application Access Token

Related NHI Mgmt Group resources: Consent Phishing and Illicit OAuth Grants Guide · Top 10 Phishing Techniques · SaaS and OAuth App Governance Guide · AiTM Phishing Guide · Phishing-Resistant MFA Guide