🔐 Recipe · Entra ID & Identity

Troubleshoot AADSTS65001 Consent Required Errors for Enterprise Applications

Diagnose and resolve 'invalid_grant' consent errors by auditing OAuth2 permission grants and granting tenant-wide admin consent for missing resources

Complexity

Intermediate

Impact

access + troubleshooting + applications + consent + entra-id

Context

Why This Matters

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.

Expected Outcomes

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 & Considerations

⚠️ 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.

Required Permissions

Permission	Why It's Needed
User.Read.All	Resolve the affected user's object ID and validate account state.
Application.Read.All	Read service principal metadata for the application with the consent issue.
DelegatedPermissionGrant.ReadWrite.All	Read existing oauth2PermissionGrants and create new grants to resolve missing consent.
AppRoleAssignment.ReadWrite.All	Manage application-role (app-only) assignments when admin consent is required.
Policy.Read.All	Read the tenant authorizationPolicy to determine whether user consent is permitted.
AuditLog.Read.All	Read sign-in logs and directory audit logs to correlate the consent failure to a specific user and app.
Directory.Read.All	Look up resource service principals (Microsoft Graph, SharePoint Online, Exchange) by appId.

The fastest way to get this done: just ask Dex. Copy the prompt below and paste it into your Dex conversation.

For IT Admins

Paste into Dex Pro

{user} is getting AADSTS65001 'consent required' / invalid_grant error when using application {app_id} (correlation ID {correlation_id}). Investigate which resource is missing consent by checking sign-in logs and existing oauth2PermissionGrants, then recommend or apply tenant-wide admin consent for the minimum required scopes.

Try in Dex Pro

For End Users

How an employee would ask Dex for help

I'm getting an error that says 'consent is required' when I try to use one of our company apps. Can you help me get access?

Try in Dex Playground

Resolve AADSTS65001 via the Entra admin center

Step 1 — Identify the application and the affected user

Collect the following from the user's error message (or browser dev tools):

The client_id / application ID in the consent URL.
The Correlation ID from the error page.
The user's UPN (email).

Step 2 — Review the sign-in log

Sign in to the Microsoft Entra admin center.
Navigate: Identity → Monitoring & health → Sign-in logs.
Filter by User = the affected user, or paste the Correlation ID into the search box.
Open the failing sign-in entry and examine the Basic info and Additional details tabs. Record the Resource name (this is the resource missing consent) and the Application.

Step 3 — Inspect the Enterprise Application's existing permissions

Navigate: Identity → Applications → Enterprise applications.
Search for and select the application (e.g., Dex CoAdmin).
Under Security, select Permissions.
Review the Admin consent and User consent tabs. Confirm whether the resource identified in Step 2 has any granted scopes listed.

Step 4 — Check the tenant user-consent policy

Navigate: Identity → Applications → Enterprise applications → Consent and permissions → User consent settings.
If user consent is set to Do not allow, users cannot self-consent — an admin must grant consent for every new resource the app requests.

Step 5 — Grant admin consent for the missing resource

Return to Enterprise applications → [your app] → Security → Permissions.
Click Grant admin consent for [Tenant Name].
Sign in as a Global Administrator or Privileged Role Administrator.
Carefully review the full consent prompt — it will now include the previously-missing resource (e.g., Office 365 SharePoint Online). Accept only if every scope is justified.
Return to the Permissions blade and confirm the new resource is listed under Admin consent.

Step 6 — Validate with the user

Ask the user to close their browser, clear cached tokens if necessary, and retry the action. If they continue to see AADSTS65001, wait 5–10 minutes for directory replication and retry.

Diagnose and resolve AADSTS65001 via Microsoft Graph

1. Resolve the affected user

GET https://graph.microsoft.com/v1.0/users?$filter=userPrincipalName eq '{user_upn}'&$select=id,displayName,userPrincipalName,accountEnabled

2. Resolve the application's service principal

GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '{app_id}'&$select=id,displayName,appId,appRoleAssignmentRequired

Record the returned id as the clientId (the service principal object ID) for subsequent calls.

3. Correlate the sign-in failure

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=userId eq '{user_id}'&$top=10&$orderby=createdDateTime desc

Find the entry matching the user's correlationId. Note the resourceId and resourceDisplayName — this is the resource that needs consent.

4. Enumerate existing delegated grants for the user

GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=clientId eq '{sp_object_id}' and principalId eq '{user_id}'

5. Enumerate tenant-wide (AllPrincipals) grants

GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=clientId eq '{sp_object_id}' and consentType eq 'AllPrincipals'

Compare the returned resourceId values to the resourceId from Step 3. A missing resource confirms the root cause.

6. Check tenant authorization policy

GET https://graph.microsoft.com/v1.0/policies/authorizationPolicy

Inspect defaultUserRolePermissions.permissionGrantPoliciesAssigned to determine whether users are allowed to consent for themselves.

7. Resolve the resource service principal (by displayName or appId)

GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=displayName eq 'Office 365 SharePoint Online'&$select=id,displayName,appId

8. Grant tenant-wide delegated consent for the missing resource

POST https://graph.microsoft.com/v1.0/oauth2PermissionGrants
Content-Type: application/json

{
  "clientId": "{sp_object_id}",
  "consentType": "AllPrincipals",
  "resourceId": "{resource_sp_object_id}",
  "scope": "Sites.Read.All AllSites.Read User.Read"
}

Note: scope is a space-separated list of delegated permissions. Always review and minimize the scopes you grant.

9. Verify

Re-run the query in Step 5 and confirm the new resourceId is present. Ask the user to retry the failing operation.

PowerShell workflow using Microsoft.Graph

This script walks through the full diagnostic path: resolve the user, resolve the app, find the failing resource from sign-in logs, inspect existing grants, and (optionally) create the missing tenant-wide grant.

Prerequisites

PowerShell 7+ with the Microsoft.Graph module installed (Install-Module Microsoft.Graph).
Account with at least Privileged Role Administrator or Application Administrator role to grant consent.

Key cmdlets used

Connect-MgGraph — authenticate with the required scopes.
Get-MgUser — resolve the user.
Get-MgServicePrincipal — resolve the app and the resource.
Get-MgAuditLogSignIn — correlate the sign-in failure.
Get-MgOauth2PermissionGrant — enumerate existing grants.
New-MgOauth2PermissionGrant — create the missing grant.

Typical flow

Run .\Resolve-ConsentError.ps1 -UserUpn 'user@contoso.com' -AppId '<guid>' -CorrelationId '<guid>' in read-only diagnostic mode.
Review the output. The script highlights which resource is missing consent and which scopes the app requires.
Re-run with -GrantConsent -Scopes 'Sites.Read.All User.Read' to create the tenant-wide grant.

Next steps

More Entra ID & Identity recipes

Browse the rest of this category in the Dex Cookbook.

Automate this with Dex Pro

Let the autonomous IT engineer run this task under your policies.

Start free

Point Dex at a tenant and try it for 30 days, no credit card.