🚨 Azure Error Guide: 'AADSTS50105' User Not Assigned to a Role for the Application

Exact Error Message

When a user (or a service principal acting on a user’s behalf) tries to sign in to an application that requires assignment, Microsoft Entra ID blocks the request and returns the following:

AADSTS50105: Your administrator has configured the application Contoso Internal Portal
(a1b2c3d4-5e6f-4071-8a9b-0c1d2e3f4a5b) to block users unless they are specifically granted
('assigned') access to the application. The signed in user
'jordan.lee@contoso.com' is blocked because they are not a direct member of a group with
access, nor had access directly assigned by an administrator. Please contact your administrator
to assign access to this application.

Correlation ID: 7f3c9a21-4b8e-4d6a-9c2f-1e5a6b7c8d90
Trace ID: 3e9d1c20-7a44-4f8b-bb19-2c6f0a8e7d31
Timestamp: 2026-06-27 14:22:08Z

The same error surfaces in the Entra Sign-in logs with failure reason “The signed in user is not assigned to a role for the application” and in your application’s redirect URI as an error=access_denied response carrying error_description text beginning with AADSTS50105.

What the Error Means

Every enterprise application (the service principal object backing an app registration in your tenant) has a property called appRoleAssignmentRequired. When this is set to true, Entra ID enforces that a user must hold an explicit app role assignment before a token is issued for that application. The assignment can be:

• A direct user-to-app assignment, or
• A group-to-app assignment where the user is a member of that group, or
• A service principal (managed identity / another app) assignment for app-to-app scenarios.

AADSTS50105 means authentication itself succeeded — Entra verified the user’s credentials — but authorization to this specific application failed because no matching assignment exists. It is purely a tenant-side access-control decision, not a credential, MFA, or token problem. The token is never issued, so your app never sees the user.

Common Causes

• Assignment required is enabled, but the user was never assigned. The most common cause: someone toggled “Assignment required?” to Yes on the enterprise app, and only a subset of users were granted access.
• The user was assigned to a group, but not to the right group. Group-based assignment requires a Microsoft Entra ID P1/P2 license; without it, group assignments to apps silently fail to grant access.
• Nested groups. Entra ID app role assignment does not honor nested (transitive) group membership. If a user is only in a child group, they are not considered assigned.
• Wrong app role. The app exposes multiple appRoles, and the user holds an assignment to a role that the app does not accept for this flow, or to a disabled role.
• A new service principal / multi-tenant app instance. A fresh consent created a second enterprise app object, and assignments live on the old one.
• CI/CD or scripted users that were excluded from the assignment list when access was provisioned.

How to Reproduce the Error

# 1. Confirm the enterprise app requires assignment
az ad sp show --id a1b2c3d4-5e6f-4071-8a9b-0c1d2e3f4a5b \
  --query "appRoleAssignmentRequired"
# returns: true

# 2. Sign in as a user who has NO assignment to that app
#    (e.g. open the app's user access URL in a private browser window)
#    https://myapps.microsoft.com/signin/<appId>

# 3. Entra blocks the sign-in and returns AADSTS50105

Any user not present on the Users and groups blade of the enterprise app will hit the error the moment they attempt interactive sign-in or an OIDC/SAML flow against that app.

Diagnostic Commands

All commands below are read-only. Run them with an account that can read directory objects.

# Confirm which tenant/identity you are operating as
az account show --query "{tenant:tenantId, user:user.name}" -o table

# Look up the enterprise application (service principal) by appId
az ad sp show --id a1b2c3d4-5e6f-4071-8a9b-0c1d2e3f4a5b \
  --query "{name:displayName, objectId:id, assignmentRequired:appRoleAssignmentRequired}" -o table

# Inspect the app registration's declared app roles (id, value, enabled state)
az ad app show --id a1b2c3d4-5e6f-4071-8a9b-0c1d2e3f4a5b \
  --query "appRoles[].{role:displayName, id:id, value:value, enabled:isEnabled}" -o table

# List every existing assignment on the enterprise app (users, groups, SPs)
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals/9c8b7a6d-1234-4f5e-8a90-aabbccddeeff/appRoleAssignedTo" \
  --query "value[].{principal:principalDisplayName, type:principalType, appRoleId:appRoleId}" -o table

# Find the objectId of the affected user to cross-check membership
az ad user show --id jordan.lee@contoso.com \
  --query "{name:displayName, objectId:id, upn:userPrincipalName}" -o table

# List groups the user belongs to (verify they are in an *assigned* group, not a nested one)
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/users/jordan.lee@contoso.com/memberOf" \
  --query "value[].{group:displayName, id:id}" -o table

# Search for the SP by name if you do not have the appId handy
az ad sp list --filter "displayName eq 'Contoso Internal Portal'" \
  --query "[].{name:displayName, appId:appId, objectId:id}" -o table

Compare the user’s objectId (and their group objectIds) against the principalId values returned by the appRoleAssignedTo query. If neither the user nor any of their directly assigned groups appears in that list, AADSTS50105 is expected.

Step-by-Step Resolution

1. Confirm assignment is actually required. From the diagnostics, if appRoleAssignmentRequired is false, the error is coming from a different app object — re-check the appId in the sign-in log’s Application ID field.

2. Pick the correct app role. Use az ad app show output to choose an enabled appRole id. If the app declares no custom roles, Entra uses the default access role id 00000000-0000-0000-0000-000000000000.

3. Assign the user (Portal — recommended). Go to Entra ID → Enterprise applications → [your app] → Users and groups → Add user/group, select the user (or a group), pick the role, and click Assign.

4. Or assign via CLI. For a single user, create the app role assignment directly through Graph:

   az rest --method POST \
     --url "https://graph.microsoft.com/v1.0/servicePrincipals/9c8b7a6d-1234-4f5e-8a90-aabbccddeeff/appRoleAssignedTo" \
     --body '{
       "principalId": "5d4c3b2a-9f8e-4a7b-8c6d-0e1f2a3b4c5d",
       "resourceId": "9c8b7a6d-1234-4f5e-8a90-aabbccddeeff",
       "appRoleId": "00000000-0000-0000-0000-000000000000"
     }'

   Here principalId is the user’s (or group’s) objectId, resourceId is the enterprise app’s objectId, and appRoleId is the chosen role.

5. Prefer groups for scale. Assign a security group instead of individual users, then manage membership in the group. Remember group-based assignment needs Entra ID P1.

6. Have the user re-authenticate. Tokens are cached; the user must sign out and back in (or wait for the existing token to expire) before the new assignment takes effect.

7. Verify by re-running the appRoleAssignedTo diagnostic — the user or group should now appear.

Prevention and Best Practices

• Standardize on group-based assignment. Drive app access from security groups so onboarding/offboarding is a single membership change, not a per-app edit.
• Avoid relying on nested groups. Because Entra does not evaluate transitive membership for app assignment, assign the flat group that users are direct members of.
• Document the appRoleAssignmentRequired decision. Treat toggling it to Yes as a change that requires updating the assignment list in the same change window.
• Automate provisioning. Wire app role assignment into your IdP/IGA pipeline or a Terraform azuread_app_role_assignment resource so access is declarative and reviewable.
• Monitor sign-in failures. Alert on repeated AADSTS50105 entries in the Entra sign-in logs — they often signal a broken access workflow. If you want a worked example of routing Entra sign-in failures into an alerting pipeline, see the Azure category.
• Use Access Reviews (P2) to periodically recertify who holds assignments to sensitive apps.

Related Errors

• AADSTS50020 — User account from identity provider does not exist in tenant. A guest/external or wrong-tenant user; assignment will not help until the account is invited and present.
• AADSTS650056 — Misconfigured application. The service principal for the resource is missing or the requested permission/scope does not exist on the app — different root cause but often confused with 50105.
• AADSTS700016 — Application not found in the directory. The client/app id in the request does not match any registered application in the tenant.
• AADSTS90094 — Admin consent required. The app requests permissions that need an administrator to grant tenant-wide consent before any user can sign in.

Frequently Asked Questions

Why does my user still get AADSTS50105 right after I assigned them? Token and sign-in session caching. Assignments are evaluated at token issuance, so an already-signed-in user keeps working with their cached state. Have them fully sign out and back in, or wait for token expiry (typically up to an hour).

Does adding a user to a nested group fix the error? No. Entra ID app role assignment ignores transitive (nested) group membership. The user must be a direct member of a group that is itself assigned to the application, or assigned individually.

Can I just turn off “Assignment required” to make the error go away? You can set appRoleAssignmentRequired to false, which lets every user in the tenant access the app. That removes the gate but also removes a security control — only do it for apps that should genuinely be open to all internal users.

What license do I need for group-based assignment? Assigning groups (rather than individual users) to an enterprise application requires Microsoft Entra ID P1 or P2. Individual user assignment works on the free tier.