A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
Expanded Definition
Consent phishing is an OAuth abuse pattern in which a user is tricked into granting an application broad delegated access to data or actions. The attacker does not need to capture a password if the victim approves the request. That makes it especially relevant to NHI governance, where tokens, app grants, and service identities can persist long after the initial click.
In practice, the attack sits at the intersection of identity, consent, and authorization. It is not the same as credential phishing, and it is not limited to one cloud vendor or one app ecosystem. Definitions vary across vendors, but the core issue is consistent: a legitimate consent flow is turned into unauthorized access. NIST Cybersecurity Framework 2.0 is useful here because it frames identity assurance, access control, and monitoring as operational duties rather than one-time setup tasks, and that mindset maps well to delegated app permissions. For broader NHI context, the Ultimate Guide to NHIs explains why weak visibility into identities and credentials amplifies downstream access risk.
The most common misapplication is treating consent phishing as a simple user training problem, which occurs when organisations ignore app permissions, token scope, and post-consent monitoring.
Examples and Use Cases
Implementing consent controls rigorously often introduces friction for users and administrators, requiring organisations to weigh fast collaboration against tighter approval review and permission governance.
- A user receives a convincing prompt to approve a “productivity” app, and the app quietly requests mail read, file access, and offline access.
- An attacker uses a rogue SaaS integration to harvest content from shared drives after a single consent event, bypassing password resets and MFA prompts.
- A security team discovers that a previously approved application still holds valid delegated access months after the employee left, revealing weak lifecycle offboarding.
- An internal automation tool is granted excessive scopes during testing, then reused in production without a formal entitlement review, creating shadow access.
- A tenant-wide admin consent flow is abused to make a malicious application appear legitimate, which makes review harder because the access path looks authorized at first glance.
These patterns are often easier to explain with an NHI lens than a traditional phishing lens, because the real asset at risk is the long-lived permission grant. The Ultimate Guide to NHIs is particularly relevant when teams need to think about delegated access as part of the identity lifecycle, not as a one-time event. For control framing, NIST Cybersecurity Framework 2.0 helps organisations connect consent review to access management and continuous monitoring rather than relying on user awareness alone.
Why It Matters in NHI Security
Consent phishing matters because the resulting access often looks legitimate to logs, auditors, and casual reviewers. Once an app token is issued, the attacker may be able to read mail, extract documents, or pivot into workflows without reusing the victim’s password. That is a classic NHI problem: a permissioned identity now has reach beyond what the organisation intended. The Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, and that same pattern appears when app consents are granted too broadly or never re-reviewed.
Security teams should treat consented applications as managed identities with a lifecycle, not as temporary user conveniences. That means inventorying app grants, limiting scopes, revoking stale tokens, and correlating unusual access with identity telemetry. It also means understanding where identity governance overlaps with Zero Trust Architecture and least privilege, because consent phishing defeats both when permissions are broad and persistent. NIST Cybersecurity Framework 2.0 reinforces the need for protected access pathways, monitoring, and timely response when delegated access is abused. Organisations typically encounter the full impact only after data exfiltration, mailbox abuse, or an impossible-travel alert forces a review, at which point consent phishing becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Consent phishing exploits overbroad app grants and token persistence, which NHI-02 seeks to constrain. |
| NIST CSF 2.0 | PR.AC-4 | PR.AC-4 covers access permissions and supports controlling consented application privileges. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous verification and least privilege for identities, including delegated apps. |
Treat consented applications as high-risk identities and enforce least privilege with continuous review.
