AADSTS501051: Client app isn't assigned to a role for the API (fix)

What does AADSTS501051 mean?

Microsoft’s error code reference doesn’t list AADSTS501051 (checked 30 October 2026).

Microsoft does document it on another page. Its protected web API guide explains how to restrict token issuance to approved client apps, by setting Assignment required? to Yes on the API’s enterprise application. Then:

Microsoft Entra ID will now check for app role assignments of client applications that request access tokens for your web API. If a client app hasn’t been assigned any app roles, Microsoft Entra ID returns an error message to the client similar to invalid_client: AADSTS501051: Application <application name> isn't assigned to a role for the <web API>.

So two things are true at once:

1. The API’s enterprise application (its service principal) has Assignment required? set to Yes.
2. The client app that asked for the token has no app role on that API.

Microsoft’s enterprise app properties page describes the switch: “If this option is set to Yes, then users and other applications or services must first be assigned this application before being able to access it.” It applies to “Applications or services for which other applications or service are requesting access tokens.”

Our reading: 501051 is the app-side twin of 50105. 50105 is a user without an assignment. 501051 is a client app without one. Microsoft doesn’t say so in those words.

Is it an attack?

Usually not. It is the assignment check doing what it was set up to do.

Pattern	Likely meaning
A new daemon or service fails on its first token request	Nobody assigned it an app role on the API yet.
A working client starts failing after a change	Someone turned on Assignment required? on the API, or removed the client’s app role assignment. Check the audit log.
A client you don’t recognise hits 501051 against an internal API	Possibly a client with valid credentials trying an API it was never granted (see below). Find out who owns that client.
Repeated 501051 from one client, every few minutes	A scheduled job retrying with no fix in sight. Noise until someone assigns the role.

Microsoft doesn’t document this, but the role check probably runs after the client has authenticated, so a 501051 from an unknown client may mean it holds working credentials in your tenant. That deserves a look, even though no token was issued.

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

Microsoft doesn’t document which sign-in table 501051 is logged in. App-only requests (client credentials) probably land in AADServicePrincipalSignInLogs. Check where it lands in your workspace:

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

Which clients are refused, and for which API:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "501051"
| summarize Rows = count(),
            IPs = make_set(IPAddress, 10),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
          by ServicePrincipalName, AppId, ResourceDisplayName, ResourceIdentity
| sort by Rows desc

Service principal sign-in rows are aggregated, so Rows is not a request count.

Who changed assignments. Microsoft’s audit log reference lists Add app role assignment to service principal, Remove app role assignment from service principal and Update service principal in the ApplicationManagement category:

AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "ApplicationManagement"
| where OperationName in ("Add app role assignment to service principal",
                          "Remove app role assignment from service principal",
                          "Update service principal")
| project TimeGenerated, OperationName,
          Target = tostring(TargetResources[0].displayName),
          ByUser = tostring(InitiatedBy.user.userPrincipalName),
          ByApp = tostring(InitiatedBy.app.displayName)
| sort by TimeGenerated desc

Our assumption: turning Assignment required? on or off is logged as Update service principal. Microsoft’s reference lists the activity but not which property changes it covers.

How do I fix AADSTS501051?

For the user: this error is between two apps, not about your account. Report it to whoever runs the app.

For developers:

1. Make sure the API exposes an app role for applications. Microsoft’s guide: in Create app role, under Allowed member types, select Applications.
2. Request the role in the client’s app registration: API permissions > Add a permission > My APIs > your API > the role.
3. Get an admin to grant consent. Microsoft: “Because these are application permissions, not delegated permissions, an admin must grant consent to use the app roles assigned to the application.”
4. Don’t branch on the AADSTS code in your code. Microsoft warns that the codes and message strings “may be changed by Microsoft at any time and without your knowledge.”

For admins:

1. Don’t fix this by setting Assignment required? back to No. That opens the API to every client in the tenant again.
2. Grant consent for the app role the client requested, or assign the role directly with Microsoft Graph PowerShell. -ServicePrincipalId and principalId are the client’s service principal. resourceId is the API’s service principal:

Connect-MgGraph -Scopes "AppRoleAssignment.ReadWrite.All"

$client = Get-MgServicePrincipal -Filter "appId eq '<client app id>'"
$api    = Get-MgServicePrincipal -Filter "appId eq '<api app id>'"

$params = @{
    principalId = $client.Id
    resourceId  = $api.Id
    appRoleId   = "<app role id from the API>"
}
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $client.Id -BodyParameter $params

3. If the API defines no app roles, Microsoft’s cmdlet reference says a default ID of 00000000-0000-0000-0000-000000000000 “can be specified to signal that the principal is assigned to the resource app without any specific app roles.” Our reading: a dedicated app role is the better choice, because the API can then check the roles claim.
4. If the client is one you don’t recognise, don’t assign anything. Find its owner first.