Entra ID AADSTS65001: User or Admin Has Not Consented to App

AADSTS65001 appears when an application asks Microsoft Entra IDThe KBY LexiconMicrosoft Entra IDA concise technical definition of Microsoft Entra ID: what it is, how it fits identity architecture, and where engineers must validate before change. Read Full Context for a token and the directory finds no record that anyone with the authority to do so has agreed to the permissions the application is requesting. The error reads as an access failure, but it is better understood as a missing authorisation record. The user may sign in correctly, and the application may be registered correctly, yet no consent grant covers the specific permissions in the request. The fix therefore depends on locating the gap, not on retrying sign-in or changing the user’s password.

This guide builds the mental model first: what consent is, where it is stored, who may give it and what the request contains. It then shows how to read the failure, choose between granting admin consent and reducing the requested permissions, and confirm the result with evidence. The exercise runs in an isolated tenant, and every production-facing decision is connected to permissions, review and escalation. Product behaviour here should be confirmed against current Microsoft Entra documentation before you act, because portal layouts and consent policies change.

#Learning Objectives

• Define consent, delegated permission, application permission, service principal and admin consent in your own words.
• Trace how a sign-in request becomes a token or an AADSTS65001 error.
• Identify the specific permission or permissions that triggered the error.
• Choose between granting admin consent and reducing the application’s requested permissions, and justify the choice.
• Verify the outcome and describe how to reverse a consent grant.

#Prerequisites

• An isolated or non-production Microsoft Entra tenant in which you can register applications. A free developer tenant is suitable if your organisation permits it.
• A test user with no administrative roles, and a separate test account holding a role able to grant consent. Which roles qualify, and which permissions each can approve, should be confirmed in current Microsoft documentation.
• Basic familiarity with OAuth 2.0The KBY LexiconOAuth 2.0OAuth 2.0 is an authorization framework, not an authentication protocol — here is its precise operational definition, roles, token flow and common failure mode. Read Full Context and OpenID ConnectThe KBY LexiconOpenID ConnectOpenID Connect is an identity layer built on OAuth 2.0 that lets a Relying Party verify who a user is via a signed ID Token, discovery metadata and published signing keys. Read Full Context vocabulary: client, resource, scope, token and redirect URI. If redirect URIs are unfamiliar, read the related guide on AADSTS50011 redirect URI mismatches first.
• Confirmation of your product version and your own permissions before applying any change. Do not use real credentials or private production data.

#Content

#

The mental model: three parties and one record

Consent involves three parties. The user or administrator owns the data and the authority to share it. The client application wants to act on that data. The resource, such as Microsoft Graph or a custom API, holds the data and enforces access. Entra ID sits between them as the authorisation server. Before it issues a token, it asks whether a recorded grant says the client may call the resource with the requested permissions on behalf of this user, or organisation-wide.

That record lives in the tenant, attached to the application’s service principal. An app registration is the global definition of the application. A service principal is its local instance in a given tenant, and it is where tenant-specific grants and assignments are stored. This distinction explains a common surprise: an application that works in its home tenant fails in another tenant, because the second tenant has no grant for it yet.

#

Delegated and application permissions

A delegated permission lets the app act as the signed-in user, limited to what both the app’s grant and the user’s own rights allow. An application permission lets the app act as itself with no user present, so it always needs administrator approval. Delegated permissions vary: some may be approved by an ordinary user, while others are marked as requiring an administrator. Which permissions fall into each class, and what tenant policy allows, should be checked in the current documentation, because tenants can restrict user consent.

#

Where the request is built

The application declares the permissions it wants in two places. Static permissions are configured on the app registration, and the sign-in request may also carry a scope parameter naming further permissions dynamically. Entra ID evaluates the union of what is requested against what has been granted. AADSTS65001 means at least one requested permission has no covering grant and the current user cannot, or has not been allowed to, grant it. A single unapproved permission is enough to fail the whole request, which is why one added scope can break a previously working application.

#

Reading the error

The error message normally includes a trace ID, a correlation ID and a timestamp, and often names the application and resource. The sign-in logs in the Entra admin centre hold the matching record, including the failure code and the application identifier. Use the logs to establish which application, which user and which resource were involved. Then compare the permissions in the request with the grants recorded on the service principal. The difference between the two lists is your diagnosis.

#

Warnings for risk

Granting admin consent is a state-changing act with tenant-wide effect. It approves the application for every user in scope, and application permissions can read or modify data with no user present. Approve only after you know who owns the application, what each permission allows and whether the publisher is trusted. Approving a permission you have not read is the most common way consent becomes a security incident. Stop if the application owner cannot be identified.

#

Production bridge

In production, separate the people who request, review and approve. Developers declare permissions, a reviewer with an appropriate administrative role approves them, and the decision is recorded in a change ticket. Use least privilege: prefer the narrowest permission that works, and prefer delegated over application permissions where a user is present. Elevated roles should be held just in time, as described in Configuring Entra ID PIM for Just-in-Time Admin Access. Revisit privileged assignments periodically, as covered in Configuring Entra ID Access Reviews for Privileged Roles. If guests or other tenants are involved, cross-tenant settings can also affect consent; see Configuring Entra ID Cross-Tenant Access for B2B Guests. Escalate to the identity team when the application is third-party, requests application permissions or touches regulated data.

#Examples

#

Worked example: a new scope breaks a working app

Input: an internal reporting app has signed users in for months with the delegated permission to read basic profiles. A developer adds a request for a permission to read all users’ directory data and deploys. The next sign-in fails with AADSTS65001.

Observation: the sign-in log shows the failure code against the reporting application, and the app registration lists two permissions. The service principal’s grants list only one.

Interpretation: the original permission is covered by an existing grant, but the new one is not, and the signed-in user cannot approve it. The error is accurate: no one with sufficient authority has consented. This is an inference from the comparison, so confirm it by checking the grants rather than assuming.

Decision: ask whether the feature truly needs directory-wide read access. If the feature only needs the signed-in user’s profile, remove the new permission and fix the code. If it genuinely needs it, route the request to an administrator for review and consent.

#

Read-only inspection

These Microsoft Graph PowerShell commands only read data. Treat the cmdlet and scope names as version-sensitive and confirm them against current documentation. Replace the placeholders with your own values.

1Connect-MgGraph -Scopes 'Application.Read.All','DelegatedPermissionGrant.Read.All'
2Get-MgServicePrincipal -Filter "appId eq '<application-client-id>'"
3Get-MgOauth2PermissionGrant -Filter "clientId eq '<service-principal-object-id>'"

The first command returns the service principal, whose object ID you need. The second lists delegated grants for that client, including the resource and the scope string. A permission missing from that string, but present in the request, is your candidate cause. Application permissions are recorded as role assignments, which this list does not show, so check those in the portal.

#Exercises

#

Exercise: reproduce and resolve AADSTS65001 in a lab tenant

Objective: trigger the error deliberately, identify the permission responsible and resolve it by both methods.

Setup: in a non-production tenant, register a single-tenant test application with a redirect URI you control, such as a local test page. Add one delegated permission that the portal marks as requiring administrator consent. Use a non-administrator test user. Do not use production data or real credentials.

1. Sign in as the test user through the application. Expect the consent error, because the user cannot approve the permission.
2. Record the trace ID, correlation ID and timestamp. Find the matching entry in the sign-in logs and note the application and resource.
3. Run the read-only commands above. Expect no grant covering the permission.
4. Resolution A: as the administrator account, review the permission, then grant admin consent for the tenant. Sign in again as the test user.
5. Cleanup and reversal: revoke the grant, or delete the test application, and confirm the error returns when you retest.
6. Resolution B: with the grant revoked, remove the permission from the registration instead and retest. The sign-in should now succeed without any administrator consent.

Expected evidence: the first sign-in fails with AADSTS65001, the logs and grants agree with your diagnosis, and each resolution changes the outcome as predicted.

Pass condition: you can explain, from evidence, why each resolution worked. Stop condition: if the tenant is shared with other people or contains real users, stop; consent affects everyone in scope. Also stop if you cannot tell which permission you are approving.

#Validation Guidance

1. Retest with the same user and application that failed. Success is a completed sign-in or token request with no AADSTS65001.
2. Check the sign-in log for a successful entry with the same application, and confirm no new failures appear for other users.
3. List the grants again and confirm they contain exactly the permissions you approved and no extras.
4. Confirm the application’s code requests no scope beyond the approved set, so that the error does not recur at the next release.
5. Record who approved what, when and why, so the decision can be audited and reviewed later.

Sign-in logs and grant lists can lag slightly, so allow a short interval before concluding that a change failed, and check the current documentation for expected propagation behaviour. If validation fails twice after correct changes, escalate with the trace ID, correlation ID, application ID and the grant list you collected.

#Common Mistakes

• Symptom: the error persists after consent. Cause: consent was granted on a different application, tenant or resource, or the request carries an extra dynamic scope. Diagnosis: compare the application ID in the log with the one you approved, then compare scopes. Correction: approve the correct object or fix the request. Recovery: revoke any grant made on the wrong application.
• Symptom: an administrator approves everything to make the error disappear. Cause: the permissions were not read. Diagnosis: review the grant list for unexpected broad scopes. Correction: remove excess permissions and re-consent. Recovery: revoke the grant and re-approve only what is needed.
• Symptom: users see the error only in a customer or partner tenant. Cause: that tenant has no service principal or grant for the app. Correction: have an administrator there review and consent. Escalate to the application owner if the publisher is unknown.
• Symptom: ordinary users are blocked although the scope looks harmless. Cause: tenant policy restricts user consent. Correction: use an approved admin consent workflow rather than loosening policy as a quick fix.
• Symptom: the error returns after a release. Cause: the developer added a scope. Correction: make permission changes part of review, so a new scope triggers a consent request before deployment.

#Key Takeaways

• AADSTS65001 means no consent record covers the permissions requested; it does not mean the sign-in or password is wrong.
• Consent is stored per tenant on the service principal, so a working app can still fail in a new tenant.
• Diagnose by comparing requested permissions with recorded grants before changing anything.
• Prefer removing unnecessary permissions to approving them, and grant admin consent only after reviewing each permission and the application owner.

Before closing the change, confirm that the retest succeeded, that the grant list matches the approved permissions and that the approval is recorded. Keep the revoke step ready, since removing the grant is the rollback boundary, and next decide whether the application’s permissions should be reduced further or reviewed on a schedule.