4 ways to fix error AADSTS65001 (The user or administrator has not consented to use the application)

Have you run into an AADSTS65001 error with your application, that tries to authenticate against Azure AD? I sure have - seems to happen at least every other time when I'm building something that uses AAD to authenticate against SharePoint.

Fixing issues with Azure AD authentication for Enterprise applications can be tricky. But a lot of the time, this is just another Azure Active Directory error that we can fix easily. This article contains multiple solutions for this issue, where granting admin consent has somehow failed.

Not all of the different solutions will work for all situations, though! That's why I included a couple of different options to try. Changes are, one of them works for you!

Note: If you came here looking for a solution to an error with code AADSTS50196, check out this post instead: How to fix error AADSTS50196 on Microsoft web properties?

Background

So, what's the reason for running into issues with Admin Consent (like when you get the dreaded AADSTS65001 error)?

Imagine this:
You're trying to add or use an app, but it requires such permissions from your tenant, that only an administrator can grant. Typically to add this kind of an app, you'll have to be a global administrator.

This is when admin consent is required for the usage of the app - and if that hasn't been granted, you'll get errors about administrators not having consented to the use of the app you're accessing. This way, you also can't add the app yourself.

Additionally, just to make the investigation just a bit more complicated, if it's an enterprise application, it could also be in an invalid state after someone tried adding the app without sufficient permissions. This could stop you from adding the app, even if you do have sufficient permissions!

Fun, right? But no worries, as there's always a workaround or two available!

I've been investigating a lot of these issues in relation to organizations using a mobile app, which the customer has been deploying as an enterprise application. Most of the things should apply for web-based apps or console programs or whatever else you're deploying, too - especially if they're enterprise applications in Azure AD!

The whole error might look something like this:

Failed to authenticate #1: 
Error: Request authority:https://login.windows.net/common resource:https://tenant.sharepoint.com clientid:[appId]  ErrorCode:invalid_grant ErrorDescription:AADSTS65001: The user or administrator has not consented to use the application with [appid]. 
Send an interactive authorization request for this user and resource.

Trace ID: 5b92cb30-6321-4e2a-99e3-b4b2b6a46c94
Correlation ID: fc8a84ec-1578-4290-b49b-42322b791a3a
Timestamp: 2020-11-17 11:49:30Z

Or you get something like this:

{  
 "error":"invalid_grant",  
 "error_description":"AADSTS65001: The user or administrator has not consented to use the application with ID [appId]"
}

How to fix these issues?

Solutions

Okay, there are a bunch of solutions, which I'm going to outline here. I'll be starting from the easy ones and progressing into the more difficult and exotic ones.

*Please note: if you have an issue, where only admin users are able to log in (without any dialogs or warnings about granting permissions), and everyone else gets an error, please jump directly to solution 2.

Time needed: 20 minutes.

How to fix error AADSTS65001?

1. Get help from an admin

   First of all, maybe it's true. Simple, but worth trying first. Maybe an admin really hasn't consented to the permissions. Just get someone with global administrator permissions to try the app, and see what happens.

   If it doesn't work for him/her either, check out the next solution.

2. Make sure that your Azure AD settings allow adding such apps

   There are a couple of properties under Azure AD Application > Manage > User settings that affect how the app is registered. Someone in your organization may have turned app registration off altogether, or limited the options severely.

   The latest Portal version has split the settings into 2 different areas. You'll have the settings concerning app registrations "local" to just this directory under Directory > Manage > User settings. The settings only affecting Enterprise Applications are accessible by either clicking a link on the aforementioned page or by navigating to Directory > Enterprise applications > User settings.

   See the 2 screenshots below - first, you can edit the "user settings" from the AAD:

   
   "User Settings" view for your Azure Active Directory instance in general. Accessible via Directory > Manage > User settings.

   And when you select to access the end-user settings from there, you'll be able to change the settings for Enterprise Applications in particular:
   
   The "User Settings" view for your Azure Active Directory instance's Enterprise Applications. It's accessible through Directory > Enterprise applications > User settings.

   Note: If you absolutely need to have the ability to register apps turned off (for example, to comply with GDPR or similar regulations), I have another article in the works on possible workarounds of Azure AD app registration.

   Ping me or send me a nudge via the comments section or through https://www.koskila.net/contact/ to remind me to finish that article!

3. Remove the app, and be sure to ask a global admin to log in once

   If the settings above were okay, check this tip out.

   This solution itself only applies to Enterprise Applications, since the method for registering a "normal app" is different from enterprise ones. Enterprise apps are registered to your Azure AD instance automatically based on their application ID. It should, more or less, just provision a service principal based on the app id, which in turn is specified in the manifest that stays wherever the enterprise app was originally registered in. From a user's point of view, this should happen automatically. It always doesn't.

   Typically, someone might try to add an enterprise application without having permission to do so. Apparently, this causes your Azure AD instance to get quite confused, and the app won't work. Not for admins (who could grant the consent), but also especially not for you.

   That means, that this particular instance of the app will not work. Ever.
   You can fix this quite easily, though. The global administrator just needs to browse to Azure AD (remember to choose the right one, though), remove the app (see screenshot below), and then log in to the app. With some apps it's pivotal, that the first person to log in is a global administrator, to make it possible for them to give admin permission in the first place (duh).

   
   Azure AD - how to remove an enterprise application (registration) from your AAD instance

4. Craft a specific log in & admin consent URL for a global admin to test

   If you don't have admin permissions, and maybe none of the global administrators can use any apps or something, maybe you could try this next. You can just send them a URL they can use to grant admin consent to an enterprise application.

   Easy? Maybe. Are they going to click a suspicious link like this without questioning it even for a second? In my experience, yes. But also, be prepared to explain what you're trying to do :)
   https://login.microsoftonline.com/**[tenant_name_in_onmicrosoft.com-form]**/oauth2/authorize?client_id=**[appId]**&response_type=code&redirect_uri=http://&nonce=1234&resource=https://graph.windows.net&prompt=admin_consent

   This URL should prompt the user (who should have global admin permissions), to grant admin consent for the app.

5. Are you using Connect-PnPOnline when getting this error?

   This is a pretty new one! Instead of doing whatever you're doing to connect, try this:

   Connect-PnPOnline -PnPManagementShell -Url

   Worked for me!

If that didn't help, you could also try enabling Legacy Auth Protocols (ask your admin for permission first!) - this article will tell you how:

https://www.koskila.net/how-to-fix-the-web-site-does-not-support-sharepoint-online-credentials-the-response-status-code-is-unauthorized-error/#Solution

Got this tip from these 2 GitHub issues - will update when there's more information!:

• https://github.com/pnp/PnP-Sites-Core/issues/2732
• https://github.com/pnp/sp-starter-kit/issues/436

Did none of these solutions work?

I've been resolving a lot of different authentication issues with Azure AD lately. Maybe something new has come up after writing this article - let me know in the comments!