IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Consent phishing — fake apps that ask for access
Priya finds a neat little app. It says "Sign in with your work account". She taps Allow and she is in. No password was stolen and no fake page fooled her. She gave the app access. Your goal: explain why this attack passes MFA, and how to limit it.
- The user clicks Allow on a real login screen. Nothing is stolen.
- The app gets a token that can outlive a password reset.
- MFA and password rules do not help.
- Best control: admin approval for risky permissions.
The login was her provider's real screen. The permission box scrolled past in a second. She approved "read all your mail" and "keep access when you are offline". Days later, security asks why a strange app is reading her inbox. She resets her password. The app keeps working.
What happened: an illicit consent grant
This is consent phishing, also called an illicit consent grant. The attacker does not steal a credential. A bad OAuth app asks the user to give it access, through the user's real login. It asks for broad scopes: named permissions, explained in Scopes, consent & least privilege. Examples are "read all mail" and "send mail as you".
The risky one is offline_access. It asks for a refresh token. This is a long-lived credential. The app can trade it for new access again and again, with no user present.
Here is the surprise. What Priya granted is a token, not a session. A password reset ends sessions. It does not cancel a consent grant. Resetting passwords and adding MFA do not help, because the app lives outside your organization. The grant works until someone revokes it.
The point is to recognize it: no malware, no fake domain, only a permission box answered too fast.
a torch app on your phone that asks to read your SMS and your contacts. A torch needs neither. When the ask does not match the job, say no.
Defenses: make broad consent a decision
🛡️ Admin-consent policy
Users cannot approve risky scopes alone. Those requests go to an admin. A common rule: users may consent only to apps from verified publishers, and only to low-risk permissions. This is the best single control.
✅ Publisher verification
Prefer apps from verified publishers. An unverified app that asks for broad access is a red flag.
📉 Least-privilege scopes
A real app asks for the narrowest scopes that do the job. "Read all mail" for a note-taking app is a mismatch to question.
🔁 Review and revoke
Review granted apps on a schedule. Revoke what is unused or unknown (see Access reviews). For AI agents the same idea lives in the agent registry and kill switch.
Consent phishing attacks a rushed human tap, not a technical weakness. Train people to read the permission screen. Mostly, use policy: sensitive grants need an admin, and you review and revoke on a schedule.
Go deeper: Watching for rogue grants
Providers' own incident guides say that normal fixes do not work here. A password reset does not cancel a grant. So watch your audit log for new "consent to application" events, most of all for unverified apps and broad scopes. When you find a rogue grant, revoke the grant itself. Then revoke the refresh tokens it holds.
🧪 Interactive lab — enable JavaScript to play with this one.
Rank the risk of the scopes a third-party app asks for with Consent Check. Then confirm that a provider can revoke a grant on demand with Logout Check.