The attack that walks right past your password and your MFA

You spent real effort making logins hard to steal: a password manager, MFA everywhere, and a watch for credential stuffing. And then a user clicks "Allow" on a consent screen for an app with a reassuring name, and an attacker gets a token that reads their email and Drive — without ever touching the password and without tripping a single MFA prompt.

That is OAuth consent phishing, and it is one of the cleaner ways into a modern account precisely because it does not look like an attack. The user is not tricked into typing a password on a fake page; they are tricked into granting a real app real access on a genuine Microsoft or Google screen. The grant is the breach. Your identity hardening is built to stop credential theft, and this attack never steals a credential.

Why the consent grant is so dangerous

When a user approves a third-party app, they hand it an access token — sometimes a long-lived refresh token — scoped to whatever permissions the app requested. The damage that follows is quiet and durable:

  • It survives a password reset. Rotating the user's password does nothing to a token granted separately; the app keeps its access until the grant is explicitly revoked. This is the same blind spot that makes stale service-account access so dangerous, now pointed at human users.
  • It survives MFA. The token is the proof of authentication; the app does not re-authenticate, so your MFA never fires again.
  • It hides in legitimate API traffic. A malicious app reading mail through the official Graph or Gmail API looks like an app reading mail. Your log and detection pipeline sees a normal API call, not a break-in.

The blast radius depends entirely on the scopes granted, which is why a token with "read all mail and files" is a high-severity finding the moment you spot it, and a token scoped to a single calendar can wait behind it.

Inventory what is already connected

You cannot watch a surface you have never looked at. The first move is to pull the list of third-party apps that already have access to your Google Workspace or Microsoft 365 tenant — and most teams are startled by how long it is.

  • Enumerate every OAuth grant, app by app, user by user: what each app is, who approved it, and what scopes it holds. This is the asset inventory instinct applied to delegated access rather than devices.
  • Flag the over-scoped and the unknown. An app nobody recognizes, or one with sweeping mailbox access for a trivial function, is exactly the kind of grant that needs a human to decide whether it stays.
  • Tie scope to your data classification. An app that can read everything in the mailbox of someone who handles restricted data is a different risk than the same app connected to a kiosk account.

This inventory is the same artifact that answers part of a security questionnaire about third-party integrations, so building it does double duty.

Reduce the surface before you have to watch it

Watching is cheaper when there is less to watch. The structural fix is admin consent control: stop letting any user grant any app sweeping access on their own.

  • Require admin approval for risky scopes. Both major platforms let you restrict user consent so that a request for broad mailbox or file access routes to an admin instead of being self-approved. This is least privilege applied to app permissions.
  • Allowlist the apps you actually use and treat everything else as a request, not a default. The smaller the set of pre-trusted apps, the easier the anomalies are to spot.
  • Run periodic access reviews of app grants, not just user roles — the same review cadence that prunes stale human access should prune stale and forgotten app tokens, which are a favorite persistence trick after a compromise.

Watch for the grant, then turn it into a finding

Reduction never reaches zero, so the rest is monitoring — and the goal is to shorten the gap between "a suspicious app was granted access" and "someone with authority decided what to do about it."

  • Watch consent and grant events in your tenant audit logs the way you watch logins: a new high-scope grant, an unfamiliar app, or a burst of consents across users after a phishing wave are all signals worth surfacing through your detection pipeline.
  • Convert a suspicious grant into a tracked finding with an owner, a severity tied to its scopes, and a clock — not a chat message that scrolls away.
  • Drive the response: revoke the grant, kill the app's tokens, and reset affected sessions — and remember that revoking the token, not resetting the password, is the step that actually evicts the attacker, the same way you would rotate exposed secrets after a leak.
  • Capture the timeline as evidence — when the grant appeared, when you caught it, what you revoked — straight into evidence collection for the auditor who later asks how you govern third-party access.

It belongs in the same program, not a separate one

Connected-app risk is not a special case; it is one more standing dimension of your posture. How many third-party apps hold high-scope access, how old those grants are, and how many are unrecognized is a number worth watching over time, alongside finding age and patch coverage. An app you deliberately keep despite broad access is a risk-acceptance decision you should record on purpose, with the exposure written down, rather than leave to inertia.

One honest caveat: a platform can inventory the apps connected to your accounts, surface new and over-scoped grants, and turn a suspicious one into a tracked finding with a timeline an auditor will accept — it organizes, watches, and proves the work. It does not revoke grants for you, block a user from clicking "Allow", make you compliant, or grant or guarantee any certification; the consent policy, the revocation, and the response are operational steps your team owns, and which obligations a given exposure triggers is a question for counsel.

The most modern account takeover never needs your password and never trips your MFA — it needs one click on "Allow". You cannot patch human curiosity, but you can decide to know what is connected: inventory the app grants, restrict who can approve the risky ones, watch for new ones, and turn the suspicious grant into a tracked finding you actually close. The token is the breach. Make sure it is one you can see.