AADSTS1003031: Admin consent failed, app lists no API permissions (fix)

What does AADSTS1003031 mean?

Microsoft’s error code reference doesn’t list AADSTS1003031 (checked 30 October 2026). The wording below comes from user reports.

A user on Microsoft Q&A posted this message after opening the tenant-wide admin consent URL for an external tenant:

AADSTS1003031: Misconfigured required resource access in client application registration.

A second Q&A user got the same text back on the redirect URI, as error=access_denied with admin_consent=True in the query string. A third got it when an admin in another organization opened an admin consent link for a multi-tenant Teams bot.

The accepted answer on the first thread comes from a Microsoft employee (Q&A moderator). It says the error occurs “when the Tenant-Wide Admin Consent URL … is used to add a multi-tenant application to a tenant, but the application registration in the resource tenant lacks API permissions.” And: “If no API permissions are defined in the app registration, the consent flow fails with the error AADSTS1003031.” This is a forum answer, not a documentation page.

The URL in question is the one Microsoft documents for tenant-wide admin consent:

https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}

A volunteer moderator on the same thread points to the requiredResourceAccess section of the app manifest, where API permissions are declared. Our reading: the message says that list is empty or unusable for consent, which matches the employee’s answer.

On the second thread, an answerer wrote that the code “doesn’t exist in our public docs” and “does seem to match the AADSTS650056 error”. AADSTS650056 looks like the documented, closest relative. It also covers a client that “has not listed any permissions”.

Is it an attack?

No. Users report it as a setup error in an app registration. The person who hits it is an admin trying to grant consent, so the attempt is deliberate and visible.

Pattern	Likely meaning
An admin hits it once while onboarding a new multi-tenant app	The app registration has no API permissions, as the Microsoft employee describes.
It happens with the client ID of a backend API	Users report passing the API’s client ID instead of the client app’s. A Q&A volunteer moderator suggests using the frontend client ID that holds the permissions. Likely because an API registration often lists no permissions of its own (unconfirmed).
It keeps happening after permissions were added	Possibly the consent URL still uses another app’s client ID. Check the client_id value.

As far as we can tell, the error stops consent from being granted, so nobody gains access through it. Still review any app you didn’t expect an admin to consent to.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table AADSTS1003031 is logged in. Our reading: the admin signs in interactively before consent, so the row, if any, is most likely in SigninLogs of the tenant where consent was attempted. Check all three tables first:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "1003031"
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable

Which app and which admin:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "1003031"
| summarize Attempts = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by UserPrincipalName, AppId, AppDisplayName, HomeTenantId, ResourceTenantId
| sort by LastSeen desc

AppId is the client ID to check. If HomeTenantId differs from your tenant, the admin was a guest. In the external-tenant case the row likely belongs to the tenant the admin consented in (unconfirmed), so the app developer’s tenant may see nothing.

How do I fix AADSTS1003031?

For the user: if you are an admin granting consent, stop and tell the app’s developer or vendor. The fix is in their app registration. If you are not an admin, pass the error and the app name to your IT team.

For developers:

1. Open the app registration in the developer’s (home) tenant. Go to API permissions.
2. Add at least one permission. The Microsoft employee’s answer gives Microsoft Graph, delegated User.Read, as an example. Add the permissions the app really needs.
3. Check that the admin consent URL uses the client ID of this app. If the app calls your own API, the client app needs a permission on that API in its own registration.
4. If external tenants must use the app, the volunteer moderator’s answer says to set Supported account types to accounts in any organizational directory, on both the client and the API registration.

For admins (in the tenant granting consent):

1. Check the client ID in the consent URL and the permissions the app requests. Microsoft says to “carefully review the permissions an application requests before granting consent.”
2. Tenant-wide admin consent needs a role such as Cloud Application Administrator, Application Administrator or Privileged Role Administrator. Privileged Role Administrator is needed for Microsoft Graph application permissions.
3. If the developer can’t fix the registration quickly, the Microsoft employee’s answer gives a workaround: create the service principal yourself.

Connect-MgGraph -Scopes Application.ReadWrite.All
New-MgServicePrincipal -BodyParameter @{ AppId = "<client id of the app>" }

Our reading: this only adds the app to your tenant. Any permissions still need consent once the developer has added them.