You’ve seen the screen a hundred times: an app wants to “Sign in with Microsoft” or “Connect your Google account,” followed by a list — read your profile, access your files, read and send email as you — and an Accept button that everyone clicks, because the meeting starts in two minutes. That screen is called OAuth consent, it’s genuinely one of the better inventions in modern security, and it has one catch worth understanding: clicking Accept can grant an outside application standing access to your data — access that quietly survives password changes and, in many setups, even MFA. Here’s how it works, how attackers abuse it, and the two settings that fix it.
What consent actually grants
When an app requests access via your Microsoft or Google identity, it isn’t learning your password — it’s issued its own key (a token) scoped to the permissions on that screen. That design is good: no password sharing, permissions are itemized, access is revocable. The catch is durability and invisibility. The grant persists until explicitly revoked — change your password, the app’s key still works, which surprises nearly everyone. And the permissions are broad in ways the friendly wording undersells: “read and send mail as you” means exactly that, programmatically, forever, from anywhere. Multiply by every employee clicking Accept on every scheduling tool, plugin, and free utility for years, and the average tenant carries dozens of standing grants nobody has ever reviewed — a shadow layer of the SaaS sprawl problem, except these apps hold live keys.
How attackers weaponize it: consent phishing
Criminals noticed something delightful about this system: why steal a password when you can get the victim to hand you a permanent key on a real Microsoft page? The play, called consent phishing or illicit consent: an email lures the target (“view the shared proposal”), the link leads to a genuine Microsoft consent screen — real URL, real branding, nothing fake to spot — requesting mail and file access for an app named something plausible like “Document Viewer Pro.” One Accept, and the attacker has durable API access to the mailbox: reading everything, setting up the payment-fraud reconnaissance, exfiltrating files — with no stolen password to change and no MFA challenge, ever again, because the token entered through the front door. It’s the phishing variant that password managers and login-page vigilance don’t catch, since the page is authentic. The tell is the request itself: legitimate document links don’t ask for standing mailbox permissions.
The fix: two settings and a habit
This has a genuinely satisfying answer, because Microsoft (and Google) built the controls — most tenants just never turn them on:
1. Require admin consent for meaningful permissions. One policy change: users can no longer self-grant apps access to mail, files, and data — requests route to an approval queue instead. This single setting kills consent phishing almost outright (the victim’s Accept becomes a request, not a grant) and puts a two-minute vendor sniff test in front of every new integration: who publishes this app, is it verified, does a scheduling tool really need send as? Pair it with the workflow so legitimate requests get answered in a day — approval that’s fast is approval people actually use; approval that’s slow teaches workarounds.
2. Audit the grants that already exist. The admin center lists every application with consented access across the tenant — and the first reading is always educational: apps from departed employees’ experiments, tools the company stopped using in 2022, the occasional entry nobody can explain at all (treat that one as an incident question, not a cleanup item — check what it accessed). Revoke ruthlessly; legitimate apps can always re-request. Then put the review on the annual calendar next to the license audit — same hour, same spirit.
And the habit, for everyone: the consent screen is a permissions decision, not a cookie banner. The one-line training version: if an app asks to read or send your mail or access your files, stop and ask IT — especially if you arrived from an email link. (It slots neatly into the awareness program.)
The bottom line
App consent is the quiet back door in cloud identity: real pages, real permissions, durable keys — and a default configuration that lets anyone in the company hand them out. Two settings (admin consent required, existing grants audited) and one sentence of training close it, at a cost of roughly an afternoon. Among the Microsoft 365 settings worth reviewing, this is the one most tenants have never touched — and the one attackers most hope stays that way.