Your user clicks Connect, signs in to their Microsoft 365 work account, and instead of returning a grant, Microsoft stops them with a “Need admin approval” screen. No code comes back, no error lands in your callback, and the user is stuck. This is the single most common blocker when connecting Microsoft tenants, and it traces to one tenant policy, not a bug in your code.
The error means the user’s organization requires an administrator to approve your Azure app before anyone in the tenant can consent to it. It surfaces as AADSTS65001 at the token layer or as a visible “Need admin approval” / “Approval required” page during sign-in. This page explains why it happens and how to clear it. For the admin-side configuration steps, see Configuring Microsoft admin approval.
Why does the need admin approval error happen?
Section titled “Why does the need admin approval error happen?”The error happens because Microsoft Entra tenants can disable user consent, so a regular user can’t approve a third-party app on their own. When your Azure app asks for permissions, Entra checks the tenant’s user consent policy. If only admins can consent, Microsoft blocks the user and returns AADSTS65001, the code for “consent required.” That 1 setting can block thousands of users across the whole tenant.
Three conditions trigger it. The tenant has set user consent to Do not allow user consent, so only an admin can approve any app. The app requests an application permission or a high-privilege scope that always requires admin consent regardless of tenant settings. Or your Azure app isn’t a verified publisher, which Microsoft has required since November 20, 2020 before users can consent to apps from outside the directory.
How do I fix the need admin approval error?
Section titled “How do I fix the need admin approval error?”Fix the error by having a tenant administrator grant consent to your Azure app once, after which every user in that organization can connect without seeing the screen. The admin approves either through the Microsoft Entra admin center or by completing the consent flow themselves. That 1 grant covers 100% of users in the tenant, so you don’t repeat it per user across hundreds of accounts.
Pick the path that matches your access. If you control the tenant, sign in as the admin and approve the app under Enterprise applications. If your user controls it, send their admin the approval request that Microsoft generates from the “Need admin approval” screen. Both routes are detailed in the admin approval setup guide. After consent is granted, the user restarts the Nylas hosted auth flow at GET /v3/connect/auth and the grant comes back normally.
When the user controls the tenant, the user-initiated approval request runs through 5 steps before they can connect. Each step happens in a different place, so it helps to know who acts where:
- The user hits the “Need admin approval” wall during sign-in and selects Request approval.
- The user types a justification (for example, “Connecting our shared inbox to the support tool”) and submits it.
- Microsoft Entra sends email to the tenant’s reviewers and lists the request under Admin consent requests in the admin center.
- An administrator opens the request, reviews the permissions your Azure app asks for, and either grants or denies it.
- The user retries the Nylas auth flow at
GET /v3/connect/auth, and because consent now exists for the whole tenant, the grant returns.
The slow part is step 4. Microsoft lets admins set a Consent request expires after window, and if no reviewer acts before it lapses, the request disappears and the user starts over. Set a realistic justification in step 2 so the reviewing admin has enough context to approve in one pass.
Need admin approval error causes and fixes
Section titled “Need admin approval error causes and fixes”The “Need admin approval” wall has 4 triggers that can block 100% of users in a tenant, and matching the right one saves hours of guessing. Each row maps a symptom to its cause and the concrete fix. The AADSTS65001 code in the table is the literal string Microsoft returns, so you can grep your auth logs for it directly to confirm the diagnosis before acting.
| Symptom | Cause | Fix |
|---|---|---|
”Need admin approval” screen, AADSTS65001 | Tenant restricts user consent to admins only | Admin grants consent to the app in the Entra admin center |
| Error only on certain scopes | App requests a permission that always needs admin consent | Admin grants tenant-wide consent for that permission |
| Error for external users, not your own staff | Azure app isn’t a verified publisher | Complete publisher verification, then enable user consent |
| Admin approved, users still blocked | User consent still set to “Do not allow” | Set user consent to allow apps from verified publishers |
What’s the difference between proactive and user-requested admin consent?
Section titled “What’s the difference between proactive and user-requested admin consent?”Proactive admin consent is an administrator approving your Azure app before any user tries to connect, while user-requested consent starts when a blocked user submits the “Need admin approval” form. Both end in the same tenant-wide grant that unblocks every account, but they differ in who starts the process and how long users wait.
With the proactive path, the admin signs in to the Microsoft Entra admin center, opens Enterprise applications, selects your app, opens Permissions, and clicks Grant admin consent. This pre-approves the app, so the first user who connects never sees the wall. It works best for tenants you onboard ahead of time, where you can hand the admin a direct link to the consent screen.
The user-requested path depends on the Admin consent workflow setting being switched on, with Users can request admin consent to apps they are unable to consent to set to Yes. If that toggle is off, the user sees a dead-end “Need admin approval” page with no Request approval button, and the only fix is the admin acting proactively. Microsoft turned this workflow off by default in 2021, so on many tenants the proactive route is the one that works.
What does the need admin approval error look like to users and developers?
Section titled “What does the need admin approval error look like to users and developers?”The user sees a full-screen Microsoft page titled “Need admin approval” or “Approval required” that names your app and lists the permissions it asked for. The developer, by contrast, usually sees nothing in the OAuth callback, because Microsoft never redirects back to your redirect_uri while the user is stuck on that screen.
For the user, the page either offers a Request approval button (when the consent workflow is on) or tells them to contact their administrator (when it’s off). No grant comes back and no account connects until an admin acts.
For the developer, the silence is the tell. If Microsoft does redirect back with an error, the callback carries error=access_denied with an error_description containing 1 of 3 verified AADSTS codes that all point at consent. Entra returns AADSTS65001 with the text “DelegationDoesNotExist - The user or administrator hasn’t consented to use the application”, and the broader admin-consent failure surfaces as AADSTS90094 with “AdminConsentRequired - Administrator consent is required.” A wrongly configured app instead returns AADSTS650056 (“Misconfigured application”), which points at a missing permission or a tenant that hasn’t consented rather than the consent policy. Log the error_description on every failed callback so you can match the exact code instead of guessing across these 3 failure modes. In practice 100% of blocked work-account requests resolve to a consent gap, not a bug in your code.
What if I can’t get admin consent?
Section titled “What if I can’t get admin consent?”If an admin won’t or can’t approve the app, the user can’t connect that work or school account, because the tenant policy is enforced by Microsoft, not by Nylas. Personal Microsoft accounts (outlook.com, hotmail.com) don’t enforce admin consent, so they connect without this screen. There is no client-side workaround for a tenant that requires admin approval.
You have two realistic options. Route the user to the Microsoft admin consent request flow so their administrator gets an email and approves it, which is the supported path. Or, if you only need a single tenant, use a Microsoft bulk authentication grant with application permissions, where the admin consents once for the whole organization. Note that Basic authentication isn’t an alternative: Microsoft deprecated it for all Exchange Online accounts on October 1, 2022.
How do I prevent the need admin approval error?
Section titled “How do I prevent the need admin approval error?”Prevent the error by requesting only the scopes you need, becoming a Microsoft verified publisher, and pre-consenting known tenants with a bulk authentication grant. These 3 measures attack the error at its source, so users in a configured tenant connect on the first try instead of hitting the wall and waiting on a reviewer.
Start with scopes. Every extra permission you request raises the chance one of them triggers mandatory admin consent, and high-privilege scopes like Place.Read.All need an admin regardless of the tenant’s user consent policy. Request the narrowest set your features use, following the scopes documentation, and add permissions later only when a feature needs them.
Next, become a verified publisher. Microsoft has required publisher verification since November 20, 2020 before a tenant can allow user consent to apps from outside its directory. Once verified, an admin can switch user consent to “Allow user consent for apps from verified publishers,” which lets ordinary users approve your app for low-risk scopes without a single admin ever touching it.
For tenants you onboard in advance, a Microsoft bulk authentication grant removes the prompt entirely. The admin consents to your app’s application permissions once, and Nylas authenticates every mailbox in that organization without individual OAuth flows.
A 200-seat onboarding walkthrough
Section titled “A 200-seat onboarding walkthrough”Picture onboarding a customer with a 200-seat Microsoft 365 tenant whose IT team has set user consent to Do not allow user consent. If you do nothing, all 200 users hit the wall the moment they click Connect. Instead, send the tenant admin a single direct link to your app’s consent page before you roll it out. The admin signs in once, reviews the delegated permissions, and clicks Grant admin consent. That 1 action pre-approves the app for the whole directory, so when the 200 users start connecting the next day, none of them sees an approval screen and each grant returns on the first attempt. The work that would have generated 200 separate approval requests collapses into 1 admin click.
What’s next
Section titled “What’s next”- Configuring Microsoft admin approval for the admin-center steps to grant and request consent
- Troubleshoot OAuth errors for
redirect_urimismatch,access_denied, and expired grants - Creating an Azure auth app to register the app and set its permissions
- Microsoft verification guide to become a verified publisher