Entra has too many OAuth2 Scope Global Consent Grant Options

28 Jan 2026 🔖 intermediate web development security
💬 EN

Last week I wrote about granting OAuth2 authorization within Microsoft Entra ID. I realized I was half-wrong about scopes – or rather, Entra offers two ways to express what looks like the same “tenant-wide delegated scope consent” outcome.

Redundant scope consent AuthZ grant mechanisms

Entra ID offers two largely unrelated mechanisms that seem to both result in the same practical effect: allowing a given OAuth 2.0 delegated permission scope (Entra API docs: PermissionScope) to appear in the scp claim of JWT Bearer/access tokens minted for a particular client + resource combination.

1. “OAuth2 Permission Grant” (API docs: OAuth2PermissionGrant).
   • Editable (see docs) only by Entra administrators with pretty high privileges. In the portal, via:
     • A “Grant admin consent” button in the “API permissions” settings blade of the Entra App Registration representing a client that will be helping humans acquire JWT bearer tokens.
     • Alternatively, a “Grant admin consent” button in the “Permissions” settings blade of the corresponding (still “client”) Entra Service Principal (a.k.a. Enterprise Application).
2. “Authorized Client Applications” (API docs: PreAuthorizedApplication).
   • Editable (see docs) by anyone with “Owner” rights over the Entra App Registration in question.
     • In the portal, via an “Add a client application” button under an “Authorized client applications” section of the “Expose an API” settings blade of the Entra App Registration representing a resource server in need of protection.
   • This is the one I suggested last week, but I’m not actually sure it’s my favorite for every use case, now that I know there are two options.

Caution

From what I can find while researching, it seems that in practice, token issuance behaves like an “or,” not an “and.” If either of these are true:

1. A tenant-wide OAuth2PermissionGrant exists joining the Resource App, Client App, and PermissionScope, or
2. A PreAuthorizedApplication exists joining the Resource App, Client App, and PermissionScope…

…Then the scope can still be minted, and Entra will issue a JWT Bearer/access token listing the PermissionScope listed in the scp claim.

So if you grant the same client the same scope via both mechanisms, you’re redundant and creating audit/revocation risk: revoking one may not actually revoke effective access if the other remains.

Preference

By and large, the LLM I researched via seemed to gravitate:

• toward preferring Oauth2PermissionGrant, because:
  • it probably involves more helpdesk tickets and governance
  • it tends to show up to the client Entra App Registration in the “API permissions” web portal blade under “Configured Permissions” or under “Other permissions granted for (tenant name here)” (depending whether they listed it as a required scope resource on their client app).
• away from PreAuthorizedApplication, because:
  • it just requires getting ahold of whoever owns the protected resource server’s Entra App Registration in question and saying “pretty please?”
    • (I confirmed that I could, over the REST API, grant a PreAuthorizedApplication for an Entra App Registration I owned, but I got a 403 Forbidden error if I tried to grant a OAuth2PermissionGrant.)

However, the LLM thought that PreAuthorizedApplication did seem pretty nifty to keep in-house application developers moving along efficiently in the case of tightly-coupled backend-frontend pairings where the same staff member owns both Entra App Registrations (representing the protected resource server and the client that will be helping humans use it).

Documentation is horrible

I can’t believe I’m the person having to document this. Microsoft, seriously.