User consent to applications: closing the door on consent phishing

Consent is a real grant of rights

When an application requests delegated permissions (reading mail, accessing files, keeping offline access), a user or an administrator has to consent. That consent creates a permission grant tied to the application's service principal in your tenant. Until it is revoked, the application can obtain tokens on the user's behalf, even after a password change if it holds a valid refresh token.

This is exactly what consent phishing abuses: the attacker publishes an application with a reassuring name, sends a genuine Microsoft sign-in link and gains access as soon as the victim accepts. There is no fake site, no captured password, and MFA is satisfied as usual.

User consent options

The consent and permissions settings for enterprise applications offer several options:

• Do not allow user consent: every request goes through an administrator;
• Allow user consent for apps from verified publishers, for selected permissions: users can only consent to permissions classified as low impact, and only for apps from verified publishers or registered in your own tenant;
• Let Microsoft manage your consent settings: Microsoft applies and maintains a default policy;
• Allow user consent for all apps: the legacy option, which should be avoided.

Labels and defaults change over time, so check the current Microsoft documentation and, above all, what is actually configured in your tenant. In the tenants we audit, the most permissive option still regularly turns up on older tenants.

Verified publishers and low-impact permissions

A verified publisher is one whose Microsoft partner account has been validated and linked to the app registration. It does not prove good intent, but it rules out applications spun up in a throwaway tenant.

Permission classification lets you flag which permissions are low impact. Keep the list short: openid, profile, email, offline_access and User.Read cover single sign-on for most applications. Never add permissions such as Mail.Read, Files.Read.All or Mail.Send.

The admin consent workflow

Restricting consent without offering an alternative pushes users towards workarounds. The admin consent workflow lets a blocked user submit a justified request, which designated reviewers then assess. Things to configure:

1. Choose reviewers who can actually evaluate the requested permissions, not just Global Administrators;
2. Turn on notifications and set an expiry period for requests;
3. Document approval criteria: publisher, permissions, business use, internal owner of the application.

Keep in mind that reviewers can only grant permissions they are themselves allowed to grant: tenant-wide consent to sensitive Microsoft Graph permissions requires a privileged role.

Detecting and responding

Consent events show up in the Entra ID audit logs. Watch in particular for consent granted to unknown multi-tenant applications and for grants covering mail or files. When in doubt, disable the service principal, revoke the permission grants and the affected user's sessions, then review the application's activity in the service principal sign-in logs.

What an audit checks

• The user consent option in force, and the group owner consent setting.
• The contents of the low-impact permission classification.
• Whether the admin consent workflow is enabled and whether the reviewers are appropriate.
• An inventory of existing delegated grants, especially those covering mail and files.
• Multi-tenant applications without a verified publisher that hold user consents.