A user opens a new app, a browser add-in or a script and gets a "Need admin approval" page instead of the app. Behind it is Microsoft Entra ID's consent framework: the app asked for permissions the user isn't allowed to grant. In this post I'll explain the consent errors you'll meet, how to decide whether the app deserves consent, and how to grant it or route it to reviewers.
Errors this guide fixes
Need admin approvalConsent promptAADSTS90094: ... needs permission to access resources in your organization that only an admin can grant.Consent promptAADSTS65001: The user or administrator has not consented to use the application with ID '...' named '...'.App error / Microsoft Entra sign-in logAADSTS65004 UserDeclinedConsentMicrosoft Entra sign-in log
Symptoms#
In a browser, the consent page shows the heading Need admin approval, the app's name (marked unverified when the publisher isn't verified) and a message like this:
AADSTS90094: ... needs permission to access resources in your organization that only an admin can grant. Please ask an admin to grant permission to this app before you can use it.Apps and scripts that request tokens without showing a prompt get this instead:
AADSTS65001: The user or administrator has not consented to use the application with ID '...' named '...'. Send an interactive authorization request for this user and resource.| Code | What it tells you |
|---|---|
AADSTS90094 | The request needs admin consent: the permissions, the app's risk or your user consent settings rule out user consent. |
AADSTS90093 | The app is requesting permissions the signed-in user isn't authorized to grant. |
AADSTS65001 | No consent exists for this app, user and permissions, and the flow couldn't show a prompt. |
AADSTS65004 | AADSTS65004 UserDeclinedConsent: the user canceled the consent prompt. |
Why it happens#
- The permission always needs an admin. Application permissions and high-privilege delegated permissions, such as
User.Read.All, can't be granted by ordinary users. - User consent is off or restricted. If users may only consent to apps from verified publishers for permissions you classified as low impact, everything else becomes an admin request.
- Assignment is required. Apps that require user assignment need admin consent, even when your user consent policy would otherwise allow the user to consent.
- Risk-based step-up consent. When Microsoft considers a user consent request risky, for example a newly registered multitenant app without publisher verification asking for non-basic permissions, it's stepped up to admin consent.
- A flow that can't prompt (65001). A silent token request, the username-and-password flow or an API calling another API on the user's behalf can't display consent, so it fails instead.
How to fix it#
1. Identify the app and what it asks for#
Get the client ID from the error, the sign-in log entry (Entra ID › Monitoring & health › Sign-in logs) or the browser address bar: the client_id and scope parameters show exactly which app and permissions were requested. Then open the app under Entra ID › Enterprise apps and review its publisher, owner and permissions. Admin consent is a decision, not a formality: if you don't recognize the app or its permissions look excessive for its purpose, stop and investigate.
2. Grant tenant-wide admin consent#
For an app you trust, open Entra ID › Enterprise apps › app › Security › Permissions and select Grant admin consent for your tenant. For apps registered in your own tenant, the same button is under App registrations › app › API permissions. If the app isn't in the tenant yet, use the admin consent URL:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=11111111-2222-3333-4444-555555555555Privileged Role Administrator can consent to any permission. Cloud Application Administrator and Application Administrator can consent to anything except Microsoft Graph application permissions (app roles).
Watch out: tenant-wide consent applies to every user. Granting it again from the portal can also replace permissions previously granted tenant-wide for that app with the ones it requests now, so read the list before you confirm.
3. Turn on the admin consent workflow#
Instead of a dead end, users can ask for approval. Go to Entra ID › Enterprise apps › Consent and permissions › Admin consent settings, set Users can request admin consent to apps they are unable to consent to to Yes, choose the reviewers (users, groups or roles that can actually grant consent), and decide on email notifications, reminders and the request expiry. Users then see a justification box and a request button on the consent page, and reviewers act on requests under Entra ID › Enterprise apps › Admin consent requests.
4. Tune user consent#
Under Entra ID › Enterprise apps › Consent and permissions › User consent settings, Microsoft recommends Allow user consent for apps from verified publishers, for selected permissions. Pair it with Permission classifications on the same page and mark only basic sign-in permissions such as openid, profile, email, offline_access and User.Read as low impact. Changes affect future consent only; existing grants stay in place.
Connect-MgGraph -Scopes "Policy.Read.All"
# No ManagePermissionGrantsForSelf.* entry means user consent is disabled
(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions.PermissionGrantPoliciesAssigned5. Fix 65001 in scripts and services#
Either grant admin consent for the delegated permissions (step 2), or have the account sign in interactively once so it can consent. If the app has no service principal in your tenant at all, you'll see a different error; see App sign-in errors: AADSTS7000215, AADSTS700016, AADSTS50011.
Verify the fix#
Have the user sign in again: there should be no consent page, and the sign-in log should show Success for the app. Then confirm the grants exist:
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"
$sp = Get-MgServicePrincipal -Filter "appId eq '11111111-2222-3333-4444-555555555555'"
# Delegated grants: ConsentType AllPrincipals = tenant-wide admin consent
Get-MgOauth2PermissionGrant -Filter "clientId eq '$($sp.Id)'" |
Select-Object ConsentType, PrincipalId, Scope
# Application permissions (app roles) granted to the app
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
Select-Object ResourceDisplayName, AppRoleIdA good result for a tenant-wide grant shows an AllPrincipals entry whose Scope lists exactly the permissions you approved. The audit log also records a Consent to application event.
Prevent it next time#
- Keep the admin consent workflow on, with reviewers who respond, so users ask instead of looking for workarounds.
- Restrict user consent to verified publishers and low-impact permissions, and review consented apps regularly; App registrations and service principals: secrets, consent and over-privileged apps shows how to hunt for over-privileged apps.
- Give line-of-business app owners the permission list to request before go-live, so admin consent happens during deployment.
- Look up other codes in the AADSTS error codes quick reference.
