Illicit Consent Grant

How Illicit Consent Grants Work

An illicit consent grant abuses normal OAuth behaviour rather than bypassing the identity provider. The attacker does not need the password once the user has approved the request, because the resulting delegated authorization can persist through refresh tokens and app consent until it is revoked or expires.

This makes the attack attractive in enterprise environments where users are trained to trust login prompts but may not distinguish a legitimate app from a malicious one. The danger is not only initial access, but the fact that the application may continue to call APIs on the user’s behalf with whatever scopes were approved.

Why It Is Dangerous

The main security issue is scope inflation: a user may approve more access than the attacker actually needs, especially if the request is framed as a productivity tool, file viewer, or collaboration helper. Once granted, that access can expose mail, files, profile data, tenant metadata, or other resources available through the connected identity platform.

Because the access is token-based and looks like a legitimate third-party integration, it can sit outside the most obvious account-takeover indicators. That can delay detection, especially when the application uses normal APIs and the user’s sign-in activity still appears valid.

How Organisations Assess Exposure

Exposure review starts with inventorying which applications have been granted delegated permissions, which users approved them, and which scopes they received. Security teams should compare those grants with business need, look for high-risk permissions, and verify whether consent was approved by the user or through an admin workflow.

Good exposure assessment also checks where the app is used, whether it is tenant-wide or user-specific, and whether the consented scopes allow mail, files, directory data, or offline access. NHIMG’s Entra ID Applications and Consent Guide is a useful starting point for understanding how consent policies, app governance, and risky grants fit together.

Detection, Revocation, and Control

Defenders should monitor consent and audit events, then correlate them with suspicious sign-in behaviour, unfamiliar apps, and unusual API use. When a grant is suspicious, revoke the permission, disable the application if needed, and review whether the attacker used the token to access mail, files, or other protected resources.

Detection is stronger when teams hunt for the whole chain, not just the approval event. NHIMG’s Entra ID Sign-In and Audit Log Detection Guide helps with that log correlation, while MITRE ATT&CK T1528 Steal Application Access Token Guide explains the token-theft and consent-abuse pattern defenders are trying to catch.

Identity and Data Impact

Illicit consent grants can create durable delegated access even after a password reset, because the compromise lives in the authorization grant, not only in the user’s login secret. That is why incident response often has to treat the consented application as part of the compromise surface.

The downstream impact can include mailbox access, document exposure, tenant reconnaissance, and continued API access until consent is removed. NHIMG’s Human vs Non-Human Identity is helpful for understanding why delegated app access behaves differently from a normal user session, and Identity Data Privacy and Consent Guide provides the privacy and delegated-access lens for consented data exposure.

Risk and Threat Considerations

Illicit consent grants are risky because they turn a brief social-engineering success into persistent application access that can survive beyond the original interaction. The attacker does not need to keep convincing the user once the grant exists, and the access path may blend into normal enterprise SaaS traffic.

Failure mechanism: The attacker induces a user to approve OAuth scopes for a malicious or compromised application, then uses the resulting delegated tokens to read or act on protected data until the grant is revoked.

Impact: The organisation can lose control of mail, files, directory data, or other connected resources, and the compromise may persist even if the user changes their password.

Practitioner Guidance

Why practitioners should care: Treat consent grants as an access-control decision, not just a user-experience event. If app approvals are not governed, the organisation can end up with durable third-party access that is difficult to spot through password-centric controls alone.

Governance implication: Establish clear ownership for consent policy, app review, and revocation so that risky grants are visible and removable. NHIMG’s Consent Phishing and Illicit OAuth Grants Guide is the most direct reference for that operating model, including consent controls, detection events, and revocation paths.

Practitioner takeaway: If a consented app cannot be justified by business need and scope, remove it quickly and investigate what data the token may already have touched.

Related resources from NHI Mgmt Group

• How does illicit consent grant work?
• What breaks when users can grant OAuth consent to risky applications?
• What breaks in practice when parental consent workflows are not easy to grant and revoke?
• How do attackers use consent grant attacks?