OAuth consent: read the permissions before granting access

Exercise: OAuth consent: read the permissions before granting access
Scenario: Synthetic cloud consent flow
Channel: Email and browser consent screen
Sender: Collaboration Admin <share@workspace-notice.example>
Subject: Quarterly plan shared with you
Message: A partner shared a quarterly plan using Document Sync Pro.
Message: The consent screen says the unverified app wants to read your profile, maintain access to data you granted, and read mail.
Message: The email says access expires in ten minutes unless you select Accept.
Displayed destination: Open shared plan
Actual destination: https://login.example/oauth2/authorize?client_id=synthetic-app
Question: What should you do at the consent screen?
Decision 1: The identity-provider domain is genuine. What is your first decision?
Option: Accept because the sign-in domain is genuine
Option: Deny, close the flow, and report the app/message
Option: Accept and avoid opening sensitive files
Preferred option: Deny, close the flow, and report the app/message
Rationale: The app is unverified, the request is unexpected, and mail plus offline access is not justified by a document-viewing story.
Decision 2: What is the strongest verification step?
Context: A teammate says the project is real but does not recognize Document Sync Pro.
Option: Reply to the sender and ask whether the app is safe
Option: Check the approved-app catalog or contact the SaaS administrator through the normal portal
Option: Search the web for positive app reviews
Preferred option: Check the approved-app catalog or contact the SaaS administrator through the normal portal
Rationale: An approved application catalog or tenant administrator can validate the exact client and permissions, not merely a similar product name.
Decision 3: What response matches that action?
Context: Assume you selected Accept before noticing the mail and offline-access permissions.
Option: Close the browser; that ends the application's access
Option: Change only your password
Option: Revoke the app grant through the official account portal and report it for token/session review
Preferred option: Revoke the app grant through the official account portal and report it for token/session review
Rationale: Recovery must remove the application grant and involve the tenant response process; closing the browser is insufficient.
Answer: A genuine identity-provider screen does not make the requesting application trustworthy.
Consent phishing can use a legitimate authorization endpoint. The decision depends on the app identity, business need, publisher verification, and requested permissions—not the login page alone.
Signals:
- Strong evidence: Unverified application requests mail and offline access. The scopes exceed the document-viewing story and can permit durable API access.
- Strong evidence: Unexpected consent request. No approved workflow or administrator introduced this exact client application.
- Contextual signal: Genuine identity-provider page. A real authorization endpoint protects credential entry but does not endorse every app requesting consent.
Safe actions:
- Deny the consent request and close the flow.
- Report the exact application name, client details, requested scopes, message, and time.
- If consent was granted, revoke the app in the official account portal and follow administrator incident guidance.
ATT&CK mapping: T1566.002 Spearphishing Link version 2.8
Mapping evidence: The synthetic targeted email contains a link that initiates a malicious OAuth consent request.
Mapping rationale: MITRE explicitly includes consent-phishing links that lure users into granting a malicious application access.
ATT&CK mapping: T1528 Steal Application Access Token version 1.5
Mapping evidence: The requested offline and mail permissions can yield application access tokens usable through APIs after consent.
Mapping rationale: The scenario's attacker objective is access through OAuth grants and resulting tokens, matching the technique's token-access behavior.
Reviewed: 2026-08-02