What a Microsoft 365 administrator is actually agreeing to at the consent screen

What is the difference between delegated and application permissions?

A delegated permission lets an application act as a signed-in user, and is bounded by what that user can already do. An application permission lets it act with no user at all, bounded only by the permission itself. That second kind is what a website widget needs, because there is no signed-in user on a public page — and it is why the consent conversation is unavoidable.

• Delegated — "read the files this user can read". Two limits apply at once: the permission, and the user's own access. Many delegated permissions can be consented by an ordinary user.
• Application — "read files". One limit applies: the permission. Microsoft's permissions reference marks every application permission as requiring admin consent, without exception.

This is the sentence worth carrying out of the article: an application permission is not "the same access, automated". It is a new, independent grant that no longer has a person's own access limiting it.

What is actually on the consent screen?

A list of permission display names, the publisher, and whether the publisher is verified. What it does not show is which sites, which mailboxes or which users the application intends to touch, because that is not part of the grant — the grant is the permission, and the intent is a promise made outside it.

Microsoft writes the display names for a broad audience, so they read softer than they are. "Read items in all site collections" is Sites.Read.All, and it means every SharePoint site in the tenant, including the ones the person clicking Accept has never heard of. "Read all users' full profiles" is User.Read.All, and it means the whole directory.

1. Read the underlying permission name, not the friendly label. The Entra admin center shows both.
2. Look up each one in Microsoft's Graph permissions reference and read the description written for developers rather than the one written for the dialog.
3. For each permission, ask what an attacker who compromised this application would be able to read. That is the true scope of the grant.
4. Ask the vendor which permissions are needed for the specific feature you are buying, and whether the rest can be removed. Frequently they can.

Is there a way to grant less than "all sites"?

For SharePoint, yes — the Sites.Selected application permission exists precisely for this. Consenting to it grants the application nothing on its own; an administrator then grants that application read, write, manage or fullcontrol on named site collections individually, and the application can reach those and nothing else.

There is a trap in it that is worth knowing before you promise it to a security review. Microsoft Graph permissions are additive, and the most permissive one wins. If the same application also holds Files.Read.All or Sites.Read.All, the narrowing that Sites.Selected was supposed to provide simply does not apply — the broader permission grants the access regardless. Sites.Selected only means what you think it means when it is the only site permission on the application.

• Grant the permission — an administrator consents to Sites.Selected in the Entra admin center. At this point the application can read no site at all.
• Grant the sites — an administrator, or an application holding Sites.FullControl.All, POSTs to /sites/{siteId}/permissions in Microsoft Graph, naming the application and the role. PnP PowerShell's Grant-PnPAzureADAppSitePermission does the same thing.
• Verify the narrowing — point the application at a site it was not granted and confirm it gets access denied. If it succeeds, a broader permission is still attached to the application.

How do you review or revoke consent later?

Every consented application appears in the Microsoft Entra admin center under Enterprise applications, and each has a Permissions blade listing exactly what it was granted and who granted it. Removing the grant there is immediate and needs no cooperation from the vendor — which is the property that makes admin consent a reasonable thing to give in the first place.

• Review on a schedule — consent granted for a project three years ago is still live. An annual pass over the Enterprise applications list finds applications nobody uses and permissions nobody remembers approving.
• Watch sign-in activity — an application that has not requested a token in months is a candidate for removal, and its absence of activity is visible in the same admin center.
• Restrict who can consent — user consent settings decide whether ordinary users can approve applications at all. Tightening that is often a larger win than auditing any single grant.

What should you ask a vendor before granting consent?

• Which permissions, and why each one? A vendor that cannot map each permission to a feature is asking for headroom rather than access.
• Is a narrower permission available? Sites.Selected instead of Sites.Read.All is the common case, and asking usually reveals whether the vendor has thought about it.
• Is the credential yours or ours? This is the managed-versus-proxy question, and it changes who is holding a token for your tenant.
• What is stored, and for how long? Reading at request time and keeping nothing is a materially different risk profile from synchronising into a vendor database.
• Where can the consented application be used? An embed restricted to a domain allowlist cannot be lifted onto someone else's website by copying a snippet.

None of these questions require a security team to be present. They are the questions the security team would ask, asked earlier, which is the cheapest possible time to discover that the answer is unacceptable.