A couple of days ago, I got a comment asking how to fix error AADSTS90008 when developing an application using Azure Active Directory
The error in question was this:
AADSTS90008: The user or administrator has not consented to use the application with ID ‘[guid]’. This happened because application is misconfigured: it must require access to Windows Azure Active Directory by specifying at least ‘Sign in and read user profile’ permission.
While the error itself is usually fairly simple, explaining what to do in a comment field turned out to be clumsy – so I decided this solution warrants another blog post (even if just barely)!
What went wrong?
AADSTS90008 can mean a couple of different things. Let’s start from simple to more complicated ones:
- Permissions to sign in has not been requested.
- Permissions to sign in have not been granted.
- Granting the permissions to sign in has failed.
Depending on the reason, the solution is of course different as well. I’m going through some simple steps to fix all of these problems – read on!
Solution to AADSTS90008
Let’s start from the simple one and continue to the more complicated ones.
How to request permissions to sign in to Azure Active Directory?
This might come off as a no-brainer, but trust me, it’s not. You wouldn’t believe how easy it is to forget to request a permission! Always worth it to make sure you actually did have this permission scope defined in the permissions you require for your application.
To do this, do the following steps:
- Navigate to https://aad.portal.azure.com
- Select “Azure Active Directory”
- “App registrations”
- Find your application from the list
- Select Settings -> “Required permissions”
- Add “Windows Azure Active Directory” API if it isn’t added already
- Add “Sign in and read user profile” delegated permission, if it isn’t selected already
- Click “Save”
How to grant the permissions to sign in for your application?
Okay – so after making sure you have the required permission scope, you still get the same error? No worries, next step is easy.
You’ll need to make sure, that you’ve granted the application access to either your data (which you can do yourself, if the Azure Active Directory’s settings allow that and the application only wants delegated permissions without admin-consent) or to all users (which requires an administrator to grant the permissions).
Navigate to the same page you had navigated in the last step to. Note the “Grant permissions” button in the “Required permissions” view. Click that and verify – and test your app again.
Be mindful of the next message that pops up – it if looks like the one below, OR if it says “Successfully granted permissions for application [yourapplication] for all users”, you’re good.
It might also say “Successfully granted permissions for application [yourapplication] for your user account”, and look like it was successful. In this case, it actually didn’t do much – because the account used wasn’t high enough administrator for the case! You’ll need to give your resident AD admin a firm kick in the butt and make him get you the global admin. That’s who you’ll need in this case.
If you, or your resident administrator friend, run into issues in this step, check out this post to see more options on how to grant the consent for the app.
At this point you should be good. But if you’re not, there’s still a few configuration steps we can try.
Granting the permissions to sign in has failed.
Let’s hope you don’t end up here! There’s probably a lot more that could be wrong, but let’s go through a couple of fixes you can try!
See the steps below – and check a screenshot below the list.
- If you’re running ASP.NET in an Azure App Service or you’re running Azure Functions, and you have registered your app for that, you could try this tweak:
- Navigate to your Azure Application Service or Function App -> Authentication/Authorization -> Authentication Providers -> Azure Active Directory
- Change the reply url of your application registration to https://[yoursite].azurewebsites.net/.auth/login/aad/callback
- Still didn’t work? Change your AAD authentication configuration into Advanced mode, add your ClientId, ClientSecret and IssuerUrl to the configuration.
- Issuer Url comes from AAD > App Registrations > Endpoints. Copy Url for FEDERATION METADATA DOCUMENT, paste it in a browser. In the EntityDescriptor tag, there is a property called entityID. Copy that value into the Issuer Url of the WebApp’s Auth config.
Didn’t fix your issue? Let me know in the comments below!
He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.
This is his personal professional (e.g. professional, but definitely personal) blog.