AADSTS65004 - User Declined or Interrupted Consent
Azure AADSTS65004 is a consent-grant failure indicating that the user either explicitly declined the requested permissions or the consent flow was interrupted before the approval could be recorded in Microsoft Entra ID.
Last reviewed: April 7, 2026|Editorial standard: source-backed technical guidance
What Does User Declined or Interrupted Consent Mean?
AADSTS65004 is an active rejection signal. Unlike AADSTS65001, which simply says consent is missing, AADSTS65004 means the user reached the consent screen but the result was not an approval. This often happens because the user clicked Cancel, closed the popup too early, or the flow was blocked by tenant policy that prevented the requested scopes from being granted.
Common Causes
- -Explicit User Denial: The user saw the requested permissions and clicked Cancel because they did not want to grant them.
- -Popup or Redirect Interruption: The browser popup was closed manually or blocked before the redirect back to the app completed.
- -Permission Level Mismatch: The app requests a scope that requires admin consent, but a standard user is being sent through the approval flow.
- -Tenant No-Consent Policy: The organization has disabled user consent, and the interactive flow cannot complete successfully for that user.
- -Session Timeout On Consent Page: The user left the consent screen open too long and the authorization round-trip expired.
How to Fix User Declined or Interrupted Consent
- 1Retry The Interaction: For many users, simply starting the sign-in again and fully completing the consent screen resolves the issue.
- 2Use Incremental Consent: Ask only for the permissions needed for the immediate task so users are less likely to cancel.
- 3Check For Admin Scopes: If the app asks for admin-only scopes, provide an explicit admin onboarding path instead of relying on ordinary-user consent.
- 4Verify Popup Behavior: If you use MSAL.js, handle popup cancellation and redirect interruptions cleanly rather than assuming consent will always finish.
Step-by-Step Diagnosis for User Declined or Interrupted Consent
- 1Check Microsoft Entra sign-in logs and confirm the failure is AADSTS65004 rather than AADSTS65001 or AADSTS90093.
- 2Inspect application logs for client-side exceptions such as popup cancellation or redirect interruption from the auth library.
- 3Review the
scopesparameter in the auth request and determine whether the requested permissions are unusually broad or admin-only. - 4Verify whether the behavior is browser-specific, especially if popup blocking, strict privacy settings, or redirect handling differ by browser.
AADSTS65001 vs AADSTS65004
- -AADSTS65001: Consent is required but has not yet been granted.
- -AADSTS65004: A consent attempt was made, but it was declined, interrupted, or otherwise not completed.
Governance vs User Intent
- -If nearly every user hits AADSTS65004, it usually points to tenant policy or scope design. If only a small subset hits it, the issue is more likely abandonment, confusion, or broken consent UX.
Implementation Examples
try {
const loginResponse = await msalInstance.loginPopup(request);
} catch (error) {
if (error.errorCode === "AADSTS65004" || error.name === "UserCancelledError") {
// User clicked Cancel or closed the window
showUserFriendlyMessage("We need these permissions to continue. Please try again when ready.");
}
}How to Verify the Fix
- -Verify that the user can successfully click Accept and receive an authorization code or token.
- -Check Enterprise Applications or app permission views in Entra to confirm the grant was actually recorded.
- -Confirm that subsequent silent token requests work without triggering another consent-related failure.
How to Prevent Recurrence
- -Pre-Consent Where Appropriate: If the app is enterprise-facing, ask a tenant admin to grant admin consent up front when policy and scope design justify it.
- -Improve UX Transparency: Explain why the app needs the requested permissions before sending users to the Entra consent screen.
- -Harden Redirect Handling: Make sure redirect URIs and app middleware do not break the round-trip during consent completion.
- -Pro tip: Never assume users will always click Accept. Build a clear fallback path for denied permissions and explain which features will remain unavailable.
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.