AADSTS650056: Misconfigured application (fix)

What does AADSTS650056 mean?

Microsoft’s description:

Misconfigured application. This could be due to one of the following: the client has not listed any permissions for ‘{name}’ in the requested permissions in the client’s application registration. Or, the admin has not consented in the tenant. Or, check the application identifier in the request to ensure it matches the configured client application identifier. Or, check the certificate in the request to ensure it’s valid. Please contact your admin to fix the configuration or consent on behalf of the tenant. Client app ID: {ID}. Please contact your admin to fix the configuration or consent on behalf of the tenant.

The reference table gives this code no PascalCase name.

Microsoft’s troubleshooting article for 650056 lists three causes:

• “The Issuer provided in the SAMLRequest is not valid.”
• “The application doesn’t have the required permissions to call Microsoft Graph APIs.”
• “The admin hasn’t consented to the permissions for the application on behalf of the tenant.”

The description also mentions a fourth check, the certificate in the request. The troubleshooting article doesn’t expand on it.

So there are two quite different families behind one code. In SAML sign-ins it is usually an identifier mismatch. In OAuth and OpenID Connect sign-ins it is usually permissions or consent.

How it differs from neighbouring consent codes

• 65001: the permissions are configured, but nobody has consented to them yet. The fix is an interactive consent.
• 90094: the user is allowed to see the consent prompt but the permissions need an admin.
• 650056: our reading is that the problem sits one step earlier. The app asked for something its own registration doesn’t list, or the request doesn’t match the app it claims to be. Consent alone may not fix it.

Is it an attack?

Almost never. 650056 comes from how an app is registered or configured, and the sign-in fails before any data is released.

Pattern	Likely meaning
650056 for every user of a new SAML app	The Identifier (Entity ID) in the enterprise app doesn’t match the Issuer the SaaS app sends. A setup mistake.
650056 for every user of an app after a vendor update	The vendor changed the Issuer or started asking for a permission the registration doesn’t list.
650056 for one app you own, after someone edited its API permissions	A permission was removed, or added without admin consent.
650056 for an app nobody in your organisation recognises	Our interpretation: a user tried an unfamiliar app. The app got nothing, but find out what it is before anyone grants it consent.

The last row is where the security work sits. 650056 often ends with the message “contact your admin to fix the configuration or consent on behalf of the tenant”, so users forward it to IT. Microsoft warns that “Granting admin consent on behalf of an organization is a sensitive operation, potentially allowing the application’s publisher access to significant portions of your organization’s data.” Check who publishes the app and what it asks for before you consent.

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

Microsoft doesn’t document which sign-in table 650056 lands in. Check where it lands in your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "650056"
| summarize Rows = count(), Apps = dcount(AppId) by SourceTable

Which apps fail, for how many users, and over which protocol. AuthenticationProtocol helps you pick the right fix, SAML or OAuth:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "650056"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Protocols = make_set(AuthenticationProtocol, 5),
            Resources = make_set(ResourceDisplayName, 5)
          by AppId, AppDisplayName
| sort by Users desc

Microsoft’s consent troubleshooting article points to the audit log for failed consent: category ApplicationManagement, status Failure, activity Consent to application. The same filter in KQL, to see if someone tried to consent and it failed:

AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "ApplicationManagement"
| where OperationName == "Consent to application"
| where Result =~ "failure"
| project TimeGenerated,
          App = tostring(TargetResources[0].displayName),
          ByUser = tostring(InitiatedBy.user.userPrincipalName),
          ResultReason
| sort by TimeGenerated desc

Whether AuthenticationProtocol is filled in on a 650056 failure isn’t documented; if it is empty, use ResourceDisplayName and the app’s own configuration to tell SAML from OAuth. ResultType is a string column, so compare it with "650056".

How do I fix AADSTS650056?

For the user: you can’t fix this yourself. Send your IT team the app name and the Client app ID from the error message.

For developers (you own the app registration):

1. In App registrations > your app > API permissions, check that every permission your code requests is listed. Microsoft’s article says to confirm the app has at least the User.Read delegated permission from Microsoft Graph.
2. Check the Status column. Microsoft’s article says that if a permission isn’t consented to, the value is Pending or blank. If it is consented to, the value is “Granted for [Tenant Name].”
3. Compare the scopes in the sign-in request with what is listed. Microsoft’s consent troubleshooting article shows the scope part of the request as an example: Openid+User.Read+Directory.Read.All.
4. Check that the application identifier in the request matches the registration, as the description asks. In Microsoft’s consent URL examples, an app that accesses itself as the resource uses the same value for app ID and App ID URI.

For admins:

1. SAML app: the Issuer in the SAML request must match the Identifier (Entity ID) in the enterprise app. Microsoft gives two fixes: update the Identifier in Entra to match the Issuer, or have the vendor send the correct Issuer.
2. App your organisation doesn’t own: sign in to the app with an admin account and select Consent on behalf of your organization on the consent screen. If no consent screen appears, Microsoft says to delete the app from Enterprise applications and sign in again.
3. Consent button not available: Microsoft’s article shows how to build a consent URL with prompt=consent on the v1 or v2.0 authorize endpoint. For tenant-wide admin consent, Microsoft’s admin consent article gives the format https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}.
4. Granting tenant-wide consent needs Privileged Role Administrator for any permission, or Cloud Application Administrator, AI Administrator or Application Administrator for anything except Microsoft Graph app roles (application permissions).
5. Before you consent, check the publisher and the permissions. Microsoft: “Permissions granted programmatically aren’t subject to review or confirmation. They take effect immediately.”