OAuth Consent Lab
The modern phish never asks for your password. It asks you to click Accept on a third-party app’s consent screen — and the app walks away with an OAuth refresh token that survives a password reset and MFA. Work a queue of real-shaped consent requests and call each one: allow it, or name why it must be blocked — an app that is over-scoped for its job, a silent offline_accesspersistence grab, a redirect to a look-alike or localhost host, an unverified publisher reaching for your mailbox, a brand impostor, or a tenant-wide admin scope. And beware the traps: a verified backup tool genuinely needs the whole mailbox. You are scored on catch rate against over-blocking — denying a legitimate app is its own failure.
The real job. More noise, a tighter clock.
Consent queue
Each app is asking to connect to a work account. Call each one: Allow, or name the reason to block.
#1 · Microsoft 365
Calendly
requested permissions
claims to: Scheduling assistant — reads and writes your calendar to book meetings.
#2 · Microsoft 365
FreePDF Merger
requested permissions
claims to: Merge and split PDF files you upload.
#3 · Google Workspace
QuickNote
requested permissions
claims to: Save notes to your Drive.
#4 · Microsoft 365
MailArchive Sync
requested permissions
claims to: Back up a copy of your inbox.
#5 · Microsoft 365
Slack
requested permissions
claims to: Sign in with your work account.
#6 · Microsoft 365
Contact Enricher
requested permissions
claims to: Enrich your contacts with company data.
#7 · Microsoft 365
Microsoft 365 Security Scanner
requested permissions
claims to: Scan your mailbox for threats (official security add-on).
#8 · Microsoft 365
Veeam Backup for Microsoft 365
requested permissions
claims to: Tenant-wide backup of Exchange, SharePoint and OneDrive (admin-installed).
#9 · Microsoft 365
TeamPulse Analytics
requested permissions
claims to: Show an org chart and team engagement dashboard.
#10 · Microsoft 365
Docusign
requested permissions
claims to: Send documents for e-signature.
#11 · Google Workspace
MailMerge Pro
requested permissions
claims to: Send mail-merge campaigns from your Gmail.
#12 · Microsoft 365
Expense Snap
requested permissions
claims to: Save scanned receipts to its own app folder.
#13 · Microsoft 365
InboxZero Assistant
requested permissions
claims to: AI that triages and replies to your email.
Catch rate vs. over-blocking
Review each consent request, then grade. So far 0/13 called, 0/9 rogue apps blocked, 0 legit app(s) wrongly blocked.
How it is scored
Catch rate = rogue apps blocked with the exact right reason.
A false positive (blocking a legitimate app) takes an extra hygiene bite — over-blocking breaks real vendors and trains users to route around IT.
Harder tiers add subtler requests and deliberate traps: a verified backup tool that truly needs broad scope, Files.ReadWrite.AppFolder (safe) vs .All (dangerous), and a clean app with a typo-squatted redirect.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based OAuth consent-phishing lab: work a queue of ~20 third-party app consent requests and decide Allow or Block — and name why.
- You judge the real consent-grant attack signals: requested scopes vs. the app’s stated function, publisher verification, the redirect URI (off-domain, localhost, raw IP, typo-squatted), single-user vs. tenant admin consent, and the app’s age and install base.
- The attack is the illicit consent grant (a.k.a. consent phishing): no password is stolen — the victim clicks Accept and the app keeps an OAuth refresh token that survives a password reset and MFA.
- You are graded on catch rate weighed against over-blocking — denying a legitimate app (a verified backup tool that truly needs broad scope, Adobe editing tenant files) carries a hygiene penalty, because over-blocking trains users to route around IT.
- Difficulty tiers add subtler requests and deliberate traps: admin-approved broad scope, Files.ReadWrite.AppFolder vs .All, and a trusted-looking app whose token returns to a typo-squatted domain.
Frequently asked questions
What is the OAuth Consent Lab?
A free, in-browser exercise where you review third-party application consent requests — the "Permissions requested" screen a user or tenant admin sees when an app asks to connect to Microsoft 365 or Google Workspace — and give each one a verdict: Allow, or a specific reason to block, such as over-scoped, a persistence grab via offline_access, a suspicious redirect URI, an unverified publisher asking for sensitive data, brand impersonation, or tenant-wide admin scopes. You are scored on how many malicious apps you deny versus how many legitimate ones you wrongly block.
What is an illicit consent grant / consent phishing?
It is an attack that skips the password entirely. The attacker sends a lure linking to a real OAuth consent screen for an app they control; when the victim clicks Accept, the app receives an OAuth access token — and, if it requested offline_access, a refresh token. That token is standing access to the mailbox, files or directory that keeps working after the victim resets their password and even after they pass MFA, because the grant is a separate authorization. Microsoft and Google both treat it as a top identity threat; defence is governing which apps can get consent and revoking risky grants.
How is it graded?
Each consent request has one correct verdict. Your catch rate is the share of risky apps you block with the exact right reason. False positives — blocking a legitimate app — carry an extra hygiene penalty, because an admin who reflexively blocks every broad-scope app breaks real vendors and pushes users toward shadow IT. A perfect run calls every request exactly right, the legitimate ones included.
Does it connect to my real tenant or any app?
No. Nothing is uploaded, no identity provider is contacted, and no real app is granted anything. The consent requests are authored, realistic snapshots bundled with the page, and every verdict is deterministic. It runs entirely in your browser — no account, no install, nothing sent anywhere.
Who is it for?
Identity and security admins who approve or govern app consent in Entra / Google Workspace, SOC analysts investigating OAuth grants, and anyone prepping for a security interview who wants to feel why offline_access on an unverified app, a raw-IP redirect, or full_access_as_app is a block — and why a verified vendor’s admin-approved broad scope is not.