AADSTS65001 - User or Admin Consent Required
Azure AADSTS65001 is a permission-grant failure indicating that the application is requesting API scopes, such as Microsoft Graph permissions, that have not yet been approved by the user or an administrator in the target tenant.
Last reviewed: April 8, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does User or Admin Consent Required Mean?
AADSTS65001 is a governance block. It occurs after successful authentication but before token issuance. Entra ID checks the requested scopes against the tenant’s consent records. If the app asks for something new, known as scope drift, or for a high-privilege permission such as Directory.ReadWrite.All, and the appropriate consent is not found, the process halts. This is one of the primary defenses against consent phishing and unauthorized data access by third-party apps.
Common Causes
- -New Scopes Added: A developer added a new API permission such as
Files.Read, but existing users have not consented to the updated permission list. - -Admin-Only Scopes: The app is requesting a scope that requires a Global Admin or another privileged admin role to approve it.
- -User Consent Disabled: The organization has disabled user consent to apps, so every new app or scope change requires an administrator.
- -Client ID or Tenant Mismatch: The app is pointing to a different app registration or environment where consent has never been granted.
- -Multi-Tenant App Onboarding: A user from a new customer or partner tenant is trying to use the app before their IT admin has approved it.
How to Fix User or Admin Consent Required
- 1Grant Admin Consent: In Entra ID > App Registrations > API Permissions, use the Grant admin consent action for the tenant if the requested scopes are legitimate.
- 2Trigger An Interactive Consent Flow: If you are the developer, avoid
prompt=noneand use an interactive flow that can display the consent screen when appropriate. - 3Review Consent Settings: Check whether the tenant allows user consent, requires verified publishers, or restricts who may approve permissions.
- 4Trim Requested Scopes: Make sure the app is not asking for broad permissions when it only needs narrower read-only access.
Step-by-Step Diagnosis for User or Admin Consent Required
- 1Inspect the error details in the browser or logs and identify the specific scope or API causing the block.
- 2Open Entra sign-in logs and check the Authentication Details or related sign-in context for interruption by a consent requirement.
- 3Verify that the
client_idin the auth request matches the app registration being audited. - 4Review tenant-level consent settings under Enterprise Applications > Consent and permissions.
Delegated vs. Application Permissions
- -Delegated Permissions: The app acts on behalf of a signed-in user. AADSTS65001 is most common here.
- -Application Permissions: The app acts as itself in a background context. These always require admin consent and never present a normal user-consent UI.
The Scope Drift Trap
- -If an app worked for months and then suddenly fails after a deployment, compare the requested scopes. Entra requires re-consent whenever the permission list expands.
Implementation Examples
const request = { scopes: ["Mail.Read", "User.Read"] };
try {
const token = await msalInstance.acquireTokenSilent(request);
} catch (error) {
if (error.errorCode === "AADSTS65001") {
// We need the user to see the consent screen
msalInstance.acquireTokenRedirect(request);
}
}# Grant admin consent for all requested permissions
az ad app permission admin-consent --id <client-id>Seen in Production
Mail feature rollout triggers new consent requirements
Frequency: high
Example: A CRM app adds a feature to sync emails. The developer adds Mail.Read to the requested scopes. Existing users are suddenly blocked by AADSTS65001 because the new scope was never consented.
Fix: Grant consent for the new scope, or redesign the app to request the additional permission only when the user actually enables that feature.
Debugging Tools
- -Entra ID App Registration UI: Best place to review and grant API permissions.
- -Entra ID Enterprise Applications: Useful for seeing whether consent exists at the tenant or user level.
- -Fiddler or Network Trace: Helps confirm the exact
scopestring being sent in the authorize request.
How to Verify the Fix
- -Ensure the user is presented with a Permissions Requested screen and can accept it when tenant policy allows.
- -Verify the admin consent status in the Azure portal shows approved permissions for the required scopes.
- -Perform silent token acquisition after consent is granted and confirm AADSTS65001 no longer appears.
How to Prevent Recurrence
- -Use Incremental Consent: Request basic profile scopes first and ask for higher privileges only when the user triggers a feature that actually needs them.
- -Include Consent In Deployment Workflows: If you manage app registrations with automation, treat new scopes as a deployment change that may require admin consent.
- -Isolate Environments: Use separate client IDs for development and production so consent changes in dev do not spill into production expectations.
- -Pro tip: In larger organizations, getting admin consent up front for the production client ID prevents repeated end-user prompts and reduces support tickets.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.