Troubleshoot AADSTS65001 Consent Required Errors for Enterprise Applications

The AADSTS65001 error ("The user or administrator has not consented to use the application") is one of the most common sign-in errors admins encounter with enterprise applications in Microsoft Entra ID. It typically surfaces when an application requests permissions (scopes) for a resource — such as Microsoft Graph, SharePoint Online, or Exchange Online — that have not yet been consented to by either the user or an administrator.

A frequent scenario: an admin grants tenant-wide consent for an app's Microsoft Graph permissions, but the same app also requires permissions for a different resource (like SharePoint Online), and that second resource was never consented to. Users then hit invalid_grant errors the moment the app tries to obtain a token for the un-consented resource.

Run this recipe when:

• A user reports AADSTS65001 or invalid_grant errors in a browser, Teams app, or partner SaaS tool.
• An app previously worked but started failing for a specific feature (e.g., SharePoint file access, mailbox reads).
• You've granted admin consent but some scopes still prompt users individually.
• Tenant-wide user consent is restricted and the app requires admin approval.

After completing this recipe you will have:

• Identified the exact application (appId), service principal, and affected user causing the consent failure.
• Enumerated all existing OAuth2 delegated permission grants for the app (per-user and tenant-wide).
• Identified which resource (Microsoft Graph, SharePoint Online, Exchange, etc.) is missing consent.
• Reviewed the tenant's authorizationPolicy to determine whether users are even permitted to grant consent themselves.
• Granted admin consent for the missing resource or documented why consent cannot be granted.
• Verified the user can successfully sign in and use the application's affected features.

⚠️ Risks & Gotchas

• Do not blindly grant admin consent. Review every requested scope. Permissions like Directory.ReadWrite.All, Mail.ReadWrite, or Sites.FullControl.All give the app broad tenant-wide capabilities that cannot be scoped to specific users after the fact.
• Verify publisher trust. Confirm the app's publisher domain and Microsoft verified publisher status before consenting. Malicious apps frequently impersonate legitimate brands.
• Consent-phishing risk. If the user arrived at the consent prompt via an email link rather than by launching the app from your SSO portal, treat it as a potential phishing attempt until proven otherwise.
• Tenant-wide consent is hard to undo at scale. Removing a granted permission requires revoking the oauth2PermissionGrant object and, for app-only permissions, the appRoleAssignment. Users with cached tokens may continue using the app for up to an hour.
• Compliance: Some regulated environments (HIPAA, FedRAMP, SOX) require a change-management ticket and approval before granting new application permissions. Check your org's policy before clicking "Grant admin consent".
• Don't reset the user's password or MFA — this is an application consent issue, not a user authentication issue.