Application consent: closing the door on illicit consent grant attacks
A single click on "Accept" can be enough to give a third-party application lasting access to a user's mailbox or files. Neither a password reset nor MFA cuts that access off. In many tenants we audit, consent settings have never been touched since the tenant was created.
How consent works
When an application asks to access data on behalf of a user, Entra ID displays a consent page listing the requested permissions: read the profile, read email, access files, maintain access while offline. If the user accepts, a delegated permission grant is recorded in the directory and a service principal is created for the application in the tenant.
Two kinds of permissions coexist:
- Delegated: the application acts on behalf of the signed-in user, within the limits of that user's own rights. A user can consent to them for themselves if the settings allow it.
- Application: the application acts on its own, with no user, across the whole tenant. Only an administrator holding the appropriate role can grant them.
Consent is therefore not just an information screen: it is a recorded grant of rights that outlives the session in which it was given.
The illicit consent grant attack
The scenario is well known and still effective. The attacker registers a multi-tenant application in their own tenant, gives it a convincing name and logo, then sends targets a link to the Microsoft consent page. The page is genuine: the domain really is Microsoft's, and the user signs in normally, MFA included. They accept permissions such as Mail.Read, Files.Read.All or offline_access.
From then on, the application holds a refresh token that lets it read the user's data without ever knowing their password. Resetting the password changes nothing while the grant exists. That is what makes the attack so dangerous: it sidesteps the usual identity defences and leaves few visible traces for the user.
Watch out. The offline_access permission, often presented as harmless, is the one that lets the application keep access over time. Combined with read access to mail, it is enough for continuous exfiltration.
Restricting user consent
The settings live in Entra ID under Enterprise applications, Consent and permissions. Three main options are available:
- Do not allow user consent: every new application requires an administrator. It is the safest option, but it must come with a request process, otherwise teams will find ways around it.
- Allow user consent for apps from verified publishers, for selected permissions: users can only consent to permissions the administrator has classified as "low impact", and only for verified publishers or apps registered in the tenant. This is the compromise Microsoft recommends.
- Allow user consent for all apps: the situation we still find far too often, and the one to move away from.
If you choose the second option, define the permission classification carefully: in practice, limiting it to openid, profile, email and User.Read covers most single sign-on scenarios without exposing sensitive data. Labels and options change regularly, so check the current state in your tenant.
The admin consent workflow
Blocking consent without offering an alternative creates frustration and informal requests. The admin consent workflow lets users request access straight from the consent page, with a justification. Requests go to designated reviewers, who can approve, deny or block the application.
- Appoint several reviewers, including at least one able to assess the risk of the requested permissions.
- Set a sensible request expiry and turn on notifications.
- Document approval criteria: verified publisher, permissions proportionate to the need, a named business owner.
Reviewing existing grants
Restricting consent does nothing about the past. You need to inventory the grants already in place. The portal shows them application by application, but for a complete inventory Microsoft Graph is more efficient: delegated permissions are exposed through oauth2PermissionGrants, application permissions through the app role assignments of service principals.
What we look for first:
- unverified applications with access to mail, files or the directory;
- applications consented to by a single user, with vague names or that appeared recently;
- tenant-wide consents given by an administrator with no record of approval;
- applications unused for a long time that still keep their permissions.
The audit log records every "Consent to application" event: it is a source to monitor continuously, not only during an audit. Depending on your licences, app governance in Microsoft Defender for Cloud Apps can also detect anomalous OAuth application behaviour.
What an audit checks
- The user consent setting and the "low impact" permission classification.
- Whether the admin consent workflow exists and works, with its reviewers.
- The inventory of delegated and application permissions granted, especially to unverified applications.
- Tenant-wide consents and their justification.
- Monitoring of consent events in the audit logs.
- The revocation procedure: removing grants, revoking sessions and disabling the service principal.