A malicious OAuth approval that gives an application delegated access to user or tenant data through a legitimate identity provider. The user authenticates normally, but the attacker persuades or tricks them into authorizing scopes that create durable token-based access.
Expanded Definition
An illicit consent grant is a malicious OAuth approval that uses a legitimate identity provider to create delegated access without needing the attacker to steal a password. The user completes a normal sign-in flow, then unknowingly approves scopes that let the application read mail, files, directory data, or other tenant resources. In NHI governance, this matters because the resulting access is token-based, durable, and often difficult to distinguish from a valid business application. Definitions vary across vendors on whether the abuse is treated as OAuth abuse, consent phishing, or delegated access fraud, but the operational risk is the same: an attacker has obtained consent that looks authentic at the protocol layer. For governance teams, the key distinction is that the identity event is not a credential reset problem alone, but an authorization trust problem tied to application scope, admin consent policy, and token lifetime. Standards such as OAuth 2.0 define the delegation model, but they do not by themselves prevent abusive consent patterns. The most common misapplication is treating illicit consent grants as routine user behavior, which occurs when consent reviews focus only on authentication logs and ignore application scopes and token issuance.
Examples and Use Cases
Implementing consent governance rigorously often introduces friction for legitimate app onboarding, requiring organisations to weigh user convenience against the risk of persistent delegated access.
- An employee approves a fake document viewer that requests mailbox and file scopes, then the attacker uses the issued refresh token to maintain access after the initial session ends.
- A tenant user is redirected to a convincing consent page that resembles a trusted productivity app, which creates a delegated grant through the identity provider rather than through credential theft.
- Administrators later discover an overbroad enterprise app with directory read permissions, a pattern that should be reviewed alongside guidance in the Ultimate Guide to NHIs.
- A security team uses Microsoft consent and permissions guidance to distinguish approved business apps from suspicious oauth consent requests.
- Privileged users are targeted with an admin-consent phishing flow, turning a single mistaken approval into tenant-wide delegated access.
These cases show why consent logging, scope review, and app allowlisting must be treated as part of identity governance, not just application onboarding.
Why It Matters in NHI Security
Illicit consent grants are a bridge between human deception and non-human persistence. Once consent is granted, the application can function as an NHI with its own access path, tokens, and scope boundaries, which means the attacker may no longer need the original user account. That is why this issue belongs in NHI security: the compromise often manifests through an application identity that inherits access from a human action. The risk is amplified when organisations fail to inventory third-party apps, monitor refresh token use, or restrict user consent for high-impact scopes. NHI Mgmt Group notes that 92% of organisations expose NHIs to third parties, raising supply chain security concerns, and Ultimate Guide to NHIs also reports that 97% of NHIs carry excessive privileges. That combination makes abused consent especially dangerous in environments with broad app permissions and weak review processes. For data handling, the resulting access can also implicate EU General Data Protection Regulation (GDPR) obligations when personal data is exposed through unauthorized delegated access. Organisations typically encounter the real impact only after mail exfiltration, file access, or tenant reconnaissance is already underway, at which point illicit consent grant investigation 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 Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | OAuth consent abuse often appears in agentic app trust and delegated tool access abuse patterns. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Illicit consent grants create durable token access and align with improper secret and token governance risks. |
| NIST CSF 2.0 | PR.AA-03 | Identity proofing and authentication alone do not stop malicious authorization through consent grants. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous authorization checks, not blind trust in initial OAuth consent. | |
| NIST AI RMF | Consent fraud is an operational AI and identity risk requiring governance, mapping, and monitoring. |
Restrict app authorization paths and validate delegated scopes before allowing autonomous tool access.
