aadsts65002 first party application preauthorization bypass error no admin con

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

Not specified by the original author.

Error message

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.

TL;DR

The app works, but nobody has approved its requested permissions in your tenant yet. Have an admin open the app registration in Entra ID, review the API permissions, and click Grant admin consent. Then ask the user to sign in again in a fresh session.

Steps

1. In Entra ID, open Enterprise applications, find the app by name, and note the application ID from the error. Expected: The app record opens and its sign-in log shows recent failed attempts with error 65001.

2. Open API permissions on the app registration and list any permission showing Not granted for [tenant]. Expected: You see the exact delegated or application permissions the app needs.

3. Have a privileged admin click Grant admin consent for [tenant] and confirm. Expected: The status column flips to Granted for every required permission.

4. Ask the user to sign out fully, close the browser, and sign in again to the app. Expected: Sign-in succeeds and the app loads its data without the 65001 error.

When to use

• AADSTS65001 appears for every user of one specific app
• A new SaaS app was just connected to Entra ID and nobody can sign in
• The app registration lists permissions with status Not granted

When not to use

• Only one user is affected (check that user's assignment instead)
• The error is AADSTS50011 reply URL mismatch (different fix)
• The app needs per-user consent and policy forbids admin consent

Why this happens

Entra ID never lets an app touch user data or directory APIs without recorded consent. If the app requests permissions after its first deployment, or was consented in a test tenant but not production, every sign-in fails with 65001 until an admin records org-wide consent.

Edge cases

• Some apps need a user to accept a consent screen themselves; admin consent does not cover those interactive flows.
• If permissions were changed after consent, the grant must be repeated for the new permissions.

Provenance

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

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

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

TL;DR: The app works, but nobody has approved its requested permissions in your tenant yet. Have an admin open the app registration in Entra ID, review the API permissions, and click Grant admin consent. Then ask the user to sign in again in a fresh session.