Fake OAuth consent request beside a phone, security shield, key, and suspicious app icon
← Rampart blog
Recovery

OAuth consent phishing: revoke the app before changing your password

Learn how OAuth consent phishing tricks you into approving a malicious app, why a password change may not be enough, and how to revoke access safely.

Rampart Editorial Team · ·

The short answer

OAuth consent phishing is a scam that persuades you to grant a malicious app access to a legitimate account. You may see a real Google or Microsoft sign-in and permission screen. If you click Allow, the app can receive an access token for the permissions you approved. It may then read or send email, access files, or use other connected data without learning your password.

Changing your password is still important, but it may not revoke an OAuth token. If you approved an app, remove that app from your account's security settings first, then change the password and review the rest of the account.

The FBI's IC3 warned on 1 September 2026 that actors observed since late 2025 were sending malicious links by email and messaging apps while impersonating officials, journalists, public figures, file-sharing services, or event organizers. The FBI says the activity can bypass password and multi-factor authentication protections because the victim authorizes the app themselves. Read the IC3 public service announcement.

How the malicious app scam works

The exact story changes, but the permission flow often looks like this:

  1. An unexpected message arrives. It may ask you to review a document, accept an event invitation, verify your identity, or open a shared file. The sender may use a name and profile that look familiar.
  2. The message sends you to a link. The link may use a shortened address, a look-alike domain, or a real cloud provider as part of the route.
  3. A legitimate provider page appears. Google, Microsoft, or another identity provider may host the sign-in and consent screen. That does not mean the third-party app requesting access is trustworthy.
  4. The app asks for permissions. The screen lists what the app can read, create, edit, send, or delete.
  5. You choose Allow. The provider issues a token to the app. The actor can use the permissions you approved through the provider's normal APIs.
  6. The actor works through the account. Depending on the permissions, the app may read or send email, access cloud files, view contacts, or make changes. Access can continue until the grant or token is revoked or expires.

OAuth itself is a legitimate authorization framework. The problem is the social engineering around a malicious app or an app asking for access that does not match the task.

A sign-in code can be a phishing handoff

Device-code phishing uses a legitimate sign-in flow in the wrong context. Microsoft describes campaigns in which a message sends the victim to a page, generates a live device code, and eventually points to the official Microsoft device-login page. When the victim enters the code, the attacker can authorize their own session without learning the victim's password. The account may still be compromised because the user approved the wrong session.

Anthropic's September 2026 threat report describes an AI-assisted operation that used device-code phishing against cloud email. Microsoft says its observed campaign used role-specific lures, dynamic code generation, and automation to keep the code valid when the victim interacted with the link. These reports describe observed campaigns, not proof that every device-login prompt is malicious.

Stop when an unexpected message asks you to enter a code, approve a device, scan a QR code, or continue a document review at a sign-in page. Open the provider directly, check which app or device is requesting access, and ask your administrator if the account is managed. Read the AI phishing email guide.

Why a real Google or Microsoft screen is not proof of safety

The provider can be genuine while the app belongs to an unrelated developer. Microsoft explains that consent phishing works because the legitimate identity platform hosts the permission screen. It advises users not to rely on an app name or domain alone, to check the publisher, and to compare the requested permissions with the task. Microsoft's consent-phishing guidance was last updated 8 January 2025.

An HTTPS padlock, a familiar logo, a verified-looking sender, or a correct spelling of your name does not answer the most important question: Why does this app need this access for this specific request?

Mexico's financial consumer authority, CONDUSEF, warned on 8 September 2026 that links sent by SMS, email, WhatsApp, social networks, and other messaging services can lead to unsafe sites or apps that collect personal or financial information. Its advice is to avoid the message link, install apps only from the official App Store or Google Play, check the developer, and contact the institution through a channel you opened yourself. This Mexican warning covers broader app-install safety. It is not evidence of a specific OAuth campaign in Mexico or elsewhere, but it is a useful check before a message sends you to an app or consent screen. Read CONDUSEF's warning.

A trusted first domain can still hide the final phishing page

Barracuda's 9 September 2026 Threat Spotlight describes a DocuSign-themed campaign that used a calendar-invite attachment and routed victims through legitimate Microsoft OAuth and Teams infrastructure. The final phishing page was generated in the browser with a blob: URL, service workers, sandboxed frames, and changing back-end controls. Checking only the first visible domain may therefore miss what the complete flow does. Treat unexpected calendar or document attachments as suspicious, verify the request outside the message, and read the final sign-in or permission request in context. Barracuda's vendor research describes one campaign. It is not a government advisory or proof of a mass consumer outbreak. Read Barracuda's Threat Spotlight and its related analysis of browser-in-the-browser trust chains.

Permission warning signs

Use the permission list as a stop sign when it is broader than the job you were asked to do.

Permission shownWhy to pause
Read, send, edit, or delete emailA document review rarely needs control of your entire mailbox. Send access can also let an app impersonate you.
Read or write files and cloud storageA single shared file should not require access to every file, folder, or drive.
ContactsA file, ticket, or event normally does not need your address book.
Calendar accessAn event tool may need a narrow calendar action, but broad read and write access deserves independent verification.
Account or directory access"Sign in" is not the same as permission to manage users, profiles, or an organization.
A publisher, website, or redirect that does not match the requestNames and domains can be spoofed. Treat a mismatch as a reason to stop, not as a small typo.

Google says linked apps can request access to Gmail, Drive, Calendar, Photos, Contacts, and other products, and that the consent screen should show the data and services requested. It also warns that an app can edit, create, or delete data when those permissions are granted. Google's linked-app guidance.

Stop before you click Allow

For a link-level check before you reach a permission screen, use how to check a link without clicking it.

What to do if you interacted with the message

The next step depends on what happened. Do not treat every click as the same incident.

Close the page and do not download anything it offered. Open your account through the provider's normal app or typed address and check for unfamiliar linked apps, sessions, devices, or security changes. Keep the message and its link as evidence, then report it to the platform and the relevant cybercrime authority.

You entered a password or verification code

Use the real provider site or app, not the message link, to change the exposed password. Sign out of other sessions, check recovery email addresses and phone numbers, review multi-factor methods, and change any other account that reused that password. Inspect connected apps too, because credential theft and consent phishing can appear in the same campaign.

If the account is work-related, contact the security or IT team immediately. They may need to reset sessions, inspect audit logs, and check whether mail forwarding or file sharing was changed.

You clicked Allow or approved an app

Revoke the app first. Then change the password, sign out other sessions, review recovery settings, and inspect activity. Revocation and password change solve different parts of the problem: revocation cuts the app's delegated access, while the password change protects the account if credentials were also exposed.

Google Account

Google's current instructions are:

  1. Open your Google Account's linked-apps page from account settings.
  2. Select the app and choose See details.
  3. Review the products and permissions listed.
  4. Choose Remove access and confirm. For a Sign in with Google link, choose Stop using Sign in with Google.

Google says removing access prevents the linked app from accessing your account, although it may not delete data the developer already copied. You can also use the page's Report this app option if the app misused your data. Google's removal steps.

Microsoft account

For a work or school account, open the Microsoft My Apps portal, select the unfamiliar app, open Manage your application, and choose Revoke Permissions for access you approved. You cannot remove permissions an administrator approved on your behalf. In that case, ask the administrator to review the app in Microsoft Entra ID and revoke the user's or tenant's consent. Microsoft explains the My Apps controls here.

For a personal Microsoft account, type account.microsoft.com yourself and sign in. Microsoft currently documents this path for connected-app permissions: Privacy > Overview > Other privacy settings > Apps and services > Apps and services that can access your data. Select the app, then choose Remove these permissions. Microsoft demonstrates that route in its personal-account connection instructions. Labels can change, so check the app name and access shown before removing anything.

Apple Account and Sign in with Apple

Apple's Sign in with Apple list is a different control from Google or Microsoft mailbox permissions. On an iPhone or iPad, open Settings > your name > Sign in with Apple, select the app or developer, and choose Delete to stop using Sign in with Apple for that app. Apple's support instructions were published 19 December 2025. This does not revoke Google or Microsoft tokens; review those providers separately.

After revocation, inspect:

Tell your employer, service provider, or contacts if messages may have been sent from your account. Preserve screenshots, timestamps, sender details, app name, permissions, and the original link. In the United States, report the incident to IC3; elsewhere, use your national cybercrime reporting route. A report does not guarantee recovery, but it helps preserve a usable record.

A provider-neutral recovery table

What happenedFirst actionThen
Link opened onlyClose it and open the provider directlyCheck sessions and linked apps; report the message
Credentials or code enteredChange the password from the real providerSign out sessions, replace recovery methods, and check forwarding
Allow clickedRevoke the app or consent grantChange the password, review activity, and notify the organization
App or file downloadedStop using the downloaded itemRun the device or security team's checks and report the incident

The Australian Signals Directorate's September 2026 access guidance makes the same distinction: OAuth tokens from an illicit consent grant can operate independently of credentials and survive credential resets, so organizations should review existing grants and revoke unused or excessive permissions. Australian Cyber Security guidance.

The Canadian Centre for Cyber Security's 1 May 2026 alert also lists an unrecognized OAuth authorization or a new vague connected app as signs of social-engineering-enabled SaaS compromise. It recommends stronger verification for recovery and device-enrollment requests. Canadian Cyber Centre alert AL26-010.

Can multi-factor authentication stop this scam?

MFA is still worth enabling, and passkeys or other phishing-resistant methods are stronger defenses against credential phishing. But consent phishing can happen after you authenticate: the user is tricked into approving an app in a legitimate provider flow. The FBI describes this as a way actors can bypass passwords and MFA, so MFA does not replace permission review and app revocation.

The UK's National Cyber Security Centre separately advises high-risk users not to share verification codes, avoid unexpected links and QR codes, enable two-step verification or passkeys, and regularly check linked devices. Those habits help reduce related account-takeover routes even when the lure arrives through a messaging app. NCSC messaging-app guidance, published 31 March 2026 and updated 14 July 2026.

Why Rampart's own OAuth connection is different

OAuth is not a warning sign by itself. Rampart uses the official Google and Microsoft OAuth flows when you choose to connect Gmail or Outlook for phishing warnings. The provider hosts the sign-in and consent screen, so Rampart does not ask for your Gmail or Microsoft password. Before you approve, confirm that the screen names Rampart and that the requested access matches email protection.

Rampart uses read-only access for connected email. It checks for phishing signals in senders, domains, links, attachments, and message text. Email body text is processed temporarily for risk analysis and discarded rather than stored on Rampart servers. Rampart cannot send, delete, or change your email.

Rampart has passed the Cloud Application Security Assessment (CASA) Tier 2 for its email integrations. CASA Tier 2 is a lab-tested, lab-verified assessment of the applicable CASA requirements for an app, its deployment infrastructure, and user-data storage locations. The App Defense Alliance explains the assurance levels. That assessment is meaningful evidence about Rampart's integration security, but it is not permission to approve a screen without reading it.

Rampart does not inspect another provider's OAuth grant, revoke tokens, manage your Google or Microsoft account, or guarantee that every malicious message will be caught. If you approved an unfamiliar app, use the provider's security controls first. Rampart can add a warning at the SMS or email stage that led you there.

Frequently asked questions

Not necessarily. In the flow described by the FBI, the provider authenticates you and the malicious app receives the permissions and token you approved. You may still have entered a password on the real provider page, so review credentials as well as app access.

Does changing my password remove a malicious app?

Not reliably. A delegated OAuth token can remain valid after a password reset. Revoke the app or consent grant, then change the password and review sessions, recovery methods, and mailbox or file activity.

MFA can stop many password-only attacks, but it cannot stop a user from approving a malicious app after a legitimate sign-in. Use MFA or passkeys and read every permission request.

Which permissions are dangerous?

Permissions that can read, send, edit, or delete email; read or write broad cloud storage; manage contacts or calendars; or administer users deserve special scrutiny. The right level depends on the task. A familiar app can still be asking for more access than it needs.

What if the app looked legitimate or had a verified publisher?

Treat that as one data point, not proof. Compare the publisher, task, domain, privacy information, and requested permissions. Microsoft notes that even a verified publisher does not remove the need to review the consent prompt.

How should I report it?

Use the provider's report option when available, tell your employer or service provider, and preserve the original message and screenshots. In the United States, file with IC3. In other countries, use the relevant national cybercrime or fraud-reporting service. Do not keep interacting with the sender while you investigate.

Sources

This guide will continue to be reviewed as provider controls, reporting paths, and official advisories change.