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|Editorial standard: source-backed technical guidance
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>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.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.