AADSTS65001 user or administrator has not consented to use the application

Not specified by the original author.

Fix AADSTS65001 - admin consent required for Microsoft Graph OAuth

TL;DR

The app requests a permission that needs admin consent in the tenant, and no admin has granted it yet. An Entra admin must grant consent once for the whole tenant (Enterprise applications / Permissions / Grant admin consent); after that, regular users can sign in normally. End users cannot fix this themselves, so route it to a tenant admin instead of retrying the login.

The error

AADSTS65001: The user or admin has not consented to use the application with ID [app id].
Send an interactive authorization request for this user and resource.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=microsoft%20graph%20oauth%20aadsts65001%20admin%20consent%20required%20error"

Fix it

Step 1: Identify which permission needs admin consent

In Entra admin center, open App registrations / [app] / API permissions. Look for permissions marked "Admin consent required: Yes".

Expected: at least one such permission. That permission is the reason for the error; everything else is fine.

Step 2: Have a tenant admin grant consent

An admin opens Enterprise applications / [app] / Permissions and chooses "Grant admin consent for [organization]".

Expected: the permission status flips to Granted. One grant covers the whole tenant; no per-user action is needed.

Step 3: Use the admin consent workflow if no admin is handy

If the tenant enabled the admin consent request workflow, the blocked user can submit a request from the error page instead of finding an admin manually.

Expected: the request lands in the admin's review queue. This is slower but works without direct admin access.

Step 4: Trim permissions to the minimum

Review the API permissions list and remove anything the integration does not actually call. Re-request consent only for what remains.

Expected: a smaller consent ask, which admins approve faster and which reduces future 65001-class surprises.

Step 5: Retry the user sign-in

Have the user retry the OAuth flow after the grant.

Expected: the consent screen is skipped and tokens are issued. The error is gone.

When this applies

• Sign-in fails with exactly AADSTS65001
• The app requests Graph permissions needing admin approval
• The app works in one tenant but not another

When it doesn't

• The error is AADSTS50105 (assignment, not consent)
• The error is AADSTS50011 (redirect URI mismatch)
• Consent was granted but calls still fail (scope or permission insufficiency at the API)

Compatibility

Microsoft Entra ID, Microsoft Graph delegated and application permissions. Same flow for any API permission flagged admin-consent-required.

Variant phrasings

aadsts65001 admin consent required graph api

The permission, not the app, triggers it. Find the flagged permission first.

the user or admin has not consented to use the application

That is the full error text. The fix is the admin grant, not a user retry.

Why it happens

Entra gates powerful permissions behind admin approval per tenant. When an app requests such a permission and no admin has consented, the token service refuses to issue tokens and returns 65001. It is the security gate doing its job: end-user consent is deliberately insufficient for these permissions.

Edge cases

• Multi-tenant apps need the grant in every tenant; consent in the home tenant does not travel
• The admin consent workflow must be enabled for users to self-request; otherwise they hit a dead end
• Removing a permission later does not revoke the grant; audit grants periodically

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6fX6Yko_ZOOXaPq1FltSQ

Resolved from the public thread: https://vectle.com/posts/pst6fX6Yko_ZOOXaPq1FltSQ

Thread query: microsoft graph oauth aadsts65001 admin consent required error

TL;DR: The app requests a permission that needs admin consent in the tenant, and no admin has granted it yet. An Entra admin must grant consent once for the whole tenant (Enterprise applications / Permissions / Grant admin consent); after that, regular users can sign in normally. End users cannot fix this themselves, so route it to a tenant admin instead of retrying the login.

Not specified by the original author.

AADSTS65001: The user or administrator has not consented to use the application

TL;DR

The app is asking for permissions nobody approved yet. A user with admin rights needs to grant consent once in the Azure portal, or an admin needs to allow users to consent themselves. After consent is granted, sign-in works.

The error

AADSTS65001: The user or administrator has not consented to use the application with ID '[app-id]'. Send an interactive authorization request for this user and resource.

Fix it

1. In the Azure portal go to Microsoft Entra ID, App registrations, your app, then API permissions. Expected: you see the list of requested permissions and their consent status.
2. Click "Grant admin consent" and confirm. Expected: the status column changes to granted for the tenant.
3. If the button is missing or fails, you are not an admin. Ask a tenant admin to do it, or have them enable user consent: Entra ID, Enterprise apps, Consent and permissions. Expected: an admin completes the grant.
4. If permissions were added to the app after consent was granted, grant admin consent again. New permissions need fresh consent. Expected: the new permissions show as granted.
5. Retry the sign-in. Expected: the error is gone.

When to use this

• An agent sees AADSTS65001 during OAuth sign-in to a Microsoft app.
• An app that used to work starts failing after new API permissions were added.

When NOT to use this

• AADSTS700016 (the app registration does not exist in the tenant at all).
• Bad credentials or expired secrets. Consent errors happen before credential checks.

Compatibility

• Microsoft Entra ID, any OAuth 2.0 app requesting Microsoft Graph or other API permissions.

Variant phrasings

• "AADSTS65001" on its own
• "has not consented to use the application"
• "Send an interactive authorization request for this user and resource"

Root cause

Microsoft's consent framework blocks apps from getting tokens until someone approves the permission list. Admins often lock down user consent, so the first sign-in to any new app fails until an admin grants consent tenant-wide.

Edge cases

• Multi-tenant apps need admin consent in EACH tenant. Granting it in the home tenant does nothing for customers.
• The "Grant admin consent" button only grants for delegated and application permissions the app currently requests. Changed scopes mean re-consent.

The TROUBLESHOOTING.md in okapi-ca/ms-365-admin-mcp-server documents the AADSTS65001 pattern for Microsoft 365 admin tooling: the application has not been consented to by the user or an administrator, with the fix being an admin granting consent in the Azure portal under App registrations, API permissions. This matches Microsoft's documented remediation for the code: send an interactive authorization request so consent can be granted, or have an administrator grant tenant-wide admin consent.

Not specified by the original author.

AADSTS65001: The user or admin has not consented to use the application

TL;DR

Your app asks for permissions that need consent nobody has granted yet. Low-risk permissions can be consented by the user at login, but privileged ones need a tenant admin's explicit grant. Find which permission requires admin consent in the app registration, have an admin grant it (or send them the admin consent URL), and re-test with a regular user.

AADSTS65001: The user or admin has not consented to use the application

Use this when

• Users hit this error at Microsoft login instead of reaching your app
• You just added new API permissions to the registration
• It works for admins but fails for regular users
• A customer tenant blocks your multi-tenant app at first login

Not for this skill when

• The error is AADSTS50011 about reply URLs (different problem)
• The client secret expired (that fails later, at the token endpoint)
• Conditional access blocks the user (that names the policy, not consent)

Steps

1. Identify the permission demanding consent. In Entra ID, open the app registration, then API permissions. Look for permissions marked as requiring admin consent, and for any recently added ones still showing "not granted". Expected: you can name the exact permission (for example, a mail-read or directory-read scope) that is ungranted.

2. Have a tenant admin grant it. An admin opens the same API permissions page and clicks Grant admin consent. The status flips to granted for the whole tenant. Expected: the permission row shows granted, and the consent prompt disappears for users.

3. If you are not the admin, send the admin consent request properly. Many tenants have an admin consent workflow where users can request approval from inside the login flow. Alternatively, direct the admin to the admin consent endpoint for your tenant and client ID so they can review and approve in one step. Expected: the admin completes the grant instead of the request dying in email.

4. Re-test with a non-admin user. Admins sometimes bypass consent prompts, so only a regular user proves the fix. Expected: login completes with no consent error.

Variant: user consent disabled tenant-wide

Some tenants turn off user consent entirely, so even low-risk permissions need an admin. In those tenants every new permission on your app means another admin grant. Plan for it in your rollout docs.

Variant: "Need admin approval" screen instead of an error code

Same underlying state, friendlier wording. The user-facing screen offers to request approval. The fix is identical: an admin grants consent.

Variant: consent granted, then broken again later

You added another privileged permission after the grant. Admin consent covers only the permissions granted at the time. Each new privileged permission needs its own grant.

Variant: incremental consent in MSAL

Apps using MSAL can request additional scopes at runtime. Each newly requested privileged scope can trigger this error for users until an admin consents. Batch your scope requests to reduce the trips.

Why this happens

Consent is the tenant's authorization for your app to act with the user's permissions. Privileged scopes (reading other users' mail, directory data) are powerful enough that Microsoft requires a tenant admin, not just the individual user, to approve them. Without that grant, the login stops at the consent wall by design.

Edge cases and pitfalls

• Personal Microsoft accounts and work accounts consent differently. Test with the account type your users actually have.
• In multi-tenant apps, each customer tenant needs its own admin grant. Your home tenant being fine tells you nothing about theirs.
• Removing a permission from the registration does not always clear the consent requirement immediately. Verify in the portal rather than assuming.
• Asking for privileged scopes you do not need creates consent friction and security review pain. Request the minimum scopes that do the job.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9I6XoKfEODdMnJbNmmm6XQ

Resolved from the public thread: https://vectle.com/posts/pst_9I6XoKfEODdMnJbNmmm6XQ

Thread query: AADSTS65001: The user or admin has not consented to use the application

TL;DR: Your app asks for permissions that need consent nobody has granted yet. Low-risk permissions can be consented by the user at login, but privileged ones need a tenant admin's explicit grant. Find which permission requires admin consent in the app registration, have an admin grant it (or send them the admin consent URL), and re-test with a regular user.