🚨 Microsoft Teams Error Guide: 'AADSTS50105' Conditional Access Blocked / User Not Assigned to Application

Overview

AADSTS50105 is an Entra ID token issuance error that fires when a user or service principal attempts to authenticate to an application but is not assigned to it — and the application’s enterprise registration has user assignment required set to true. A Conditional Access block is a related but distinct failure: a CA policy evaluates the sign-in and returns an error before or after token issuance, typically requiring MFA, a compliant device, or blocking the sign-in outright.

Both errors surface in the OAuth 2.0 token response or OIDC redirect rather than in a Graph API response body. The AADSTS50105 token error:

{
  "error": "unauthorized_client",
  "error_description": "AADSTS50105: The signed in user 'james.joyner@contoso.com' is not assigned to a role for the application '00000000-1111-2222-3333-444444444444' (TeamsIntegrationApp). Ensure that the user is assigned to the app. Trace ID: d4e5f6a7-b8c9-0123-defg-456789012345. Correlation ID: e5f6a7b8-c9d0-1234-efgh-567890123456.",
  "error_codes": [50105],
  "timestamp": "2026-06-23 12:01:14Z",
  "trace_id": "d4e5f6a7-b8c9-0123-defg-456789012345",
  "correlation_id": "e5f6a7b8-c9d0-1234-efgh-567890123456"
}

A Conditional Access block returns AADSTS53003 (CA policy blocks access) or AADSTS50158 (external security challenge not satisfied):

{
  "error": "conditional_access_policy",
  "error_description": "AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Trace ID: f6a7b8c9-d0e1-2345-fghi-678901234567.",
  "error_codes": [53003],
  "suberror": "message_only"
}

These errors block all subsequent Graph API calls because no token is issued. They appear in Azure AD sign-in logs, in the OAuth error response to the calling app, and are surfaced to users in the Teams client as “You don’t have access to this app.”

Symptoms

• Users or service accounts cannot sign in to a Teams-integrated application; they see “AADSTS50105” in browser error pages or app logs.
• Automation using client credentials or ROPC flows returns 401/400 with unauthorized_client or conditional_access_policy in the token response.
• Sign-in logs in Entra ID show Failure with error code 50105 or 53003 for affected users.
• Some users can authenticate while others cannot — points to assignment policy or CA policy targeting a specific group.
• Service principal (non-interactive) flows work but user (delegated) flows fail, or vice versa.

# Attempt to acquire a delegated token (will fail if user not assigned or CA blocks)
curl -s -X POST \
  "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=password&username=james.joyner@contoso.com&password=$USER_PW&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=https://graph.microsoft.com/.default"

{
  "error": "unauthorized_client",
  "error_description": "AADSTS50105: The signed in user 'james.joyner@contoso.com' is not assigned to a role for the application '00000000-1111-2222-3333-444444444444' (TeamsIntegrationApp)...",
  "error_codes": [50105],
  "timestamp": "2026-06-23 12:01:14Z",
  "trace_id": "d4e5f6a7-b8c9-0123-defg-456789012345"
}

Common Root Causes

1. “User assignment required” is enabled but the user is not assigned

When appRoleAssignmentRequired is true on the enterprise application’s service principal, only users (or groups) explicitly assigned to the application can receive tokens. Any unassigned user gets AADSTS50105.

# Check appRoleAssignmentRequired for the service principal
SP_ID=$(az ad sp show --id $CLIENT_ID --query id -o tsv)
curl -s -X GET \
  "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID?$select=id,displayName,appRoleAssignmentRequired" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '{displayName, appRoleAssignmentRequired}'

{
  "displayName": "TeamsIntegrationApp",
  "appRoleAssignmentRequired": true
}

# Check whether this user has an assignment
curl -s -X GET \
  "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignedTo" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | \
  jq '.value[] | select(.principalDisplayName=="James Joyner") | {principalDisplayName, appRoleId}'

(empty — no assignment found)

The user has no assignment. Either add them directly or assign a group they belong to.

2. Conditional Access policy blocks the specific user or client app

A CA policy may target the enterprise application and require MFA, a compliant device, or a specific location — or may outright block the sign-in for certain users, groups, or sign-in conditions. The sign-in log shows the exact policy and the reason it fired.

# List sign-in logs for the affected user (requires AuditLog.Read.All)
curl -s -X GET \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=userPrincipalName eq 'james.joyner@contoso.com' and appId eq '$CLIENT_ID'&\$top=5&\$orderby=createdDateTime desc" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | \
  jq '.value[] | {createdDateTime, status: .status.errorCode, failureReason: .status.failureReason, conditionalAccessStatus, appliedConditionalAccessPolicies}'

{
  "createdDateTime": "2026-06-23T12:01:14Z",
  "status": 53003,
  "failureReason": "Access has been blocked by Conditional Access policies.",
  "conditionalAccessStatus": "failure",
  "appliedConditionalAccessPolicies": [
    {
      "id": "aaaa1111-bbbb-2222-cccc-333344445555",
      "displayName": "Require compliant device for Teams apps",
      "enforcedGrantControls": ["compliantDevice"],
      "result": "failure"
    }
  ]
}

The policy "Require compliant device for Teams apps" is blocking the sign-in because the device is not Intune-compliant.

3. Service principal not assigned when the app uses client credentials

For client-credentials (app-only) flows, appRoleAssignmentRequired applies to the calling service principal, not to a user. If a service principal from another tenant or a managed identity is calling the app and is not in the assigned list, it gets AADSTS50105 or a similar authorization error.

# Check app role assignments for service principals (not users)
curl -s -X GET \
  "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignedTo?$filter=principalType eq 'ServicePrincipal'" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | \
  jq '.value[] | {principalDisplayName, principalType, appRoleId}'

[]

No service principals are assigned. The calling service principal (e.g., a Logic App managed identity) needs an explicit assignment.

4. Conditional Access policy requiring MFA but the sign-in is non-interactive

Non-interactive flows (client credentials, refresh tokens from service accounts) cannot satisfy MFA challenges. If a CA policy targeting the application requires MFA and the sign-in is non-interactive, it fails with AADSTS50158 or AADSTS53003.

# Inspect the CA policy details to understand the MFA requirement
curl -s -X GET \
  "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/aaaa1111-bbbb-2222-cccc-333344445555" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | \
  jq '{displayName, state, conditions: {users: .conditions.users, applications: .conditions.applications}, grantControls}'

{
  "displayName": "Require MFA for TeamsIntegrationApp",
  "state": "enabled",
  "conditions": {
    "users": { "includeUsers": ["All"] },
    "applications": { "includeApplications": ["00000000-1111-2222-3333-444444444444"] }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

"includeUsers": ["All"] means service accounts cannot bypass MFA. Exclude the service account or use a named location exclusion for trusted IPs running automation.

5. Group-based assignment but the user’s group membership has not replicated

When assignment is done via group, Entra ID must evaluate group membership at token-issuance time. If a user was recently added to the group, or group membership is synced from on-premises AD and replication is lagging, the user may still receive AADSTS50105 until the membership syncs.

# Check whether the user is a transitive member of the assigned group
GROUP_ID="gggg5555-hhhh-6666-iiii-777788889999"
curl -s -X GET \
  "https://graph.microsoft.com/v1.0/groups/$GROUP_ID/transitiveMembers?$filter=id eq '$USER_OID'" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.value | length'

0

The user is not yet a transitive member. Check AD Connect sync status and force a sync cycle if on-premises:

# On the AD Connect server (PowerShell equivalent via az CLI is not available; use local PS)
# Start-ADSyncSyncCycle -PolicyType Delta
# Check Entra ID sync health
az ad user show --id james.joyner@contoso.com --query "onPremisesSyncEnabled" -o tsv
az ad user show --id james.joyner@contoso.com --query "onPremisesLastSyncDateTime" -o tsv

true
2026-06-23T11:45:00Z

A sync time of 16 minutes ago with the group added at 12:00 means membership has not yet propagated. Wait for the next delta sync or trigger one manually.

6. Wrong application ID in the token request (calling the wrong app registration)

If the client_id in the token request points to a different app registration than the one protected by the CA policy or assignment requirement, the error still appears but reflects the wrong application’s policy state. This is common when multiple environments (dev/staging/prod) share a tenant with different app registrations.

# Verify the app registration the token was requested for
az ad app show --id $CLIENT_ID --query "{displayName:displayName, appId:appId, identifierUris:identifierUris}" -o json

{
  "displayName": "TeamsIntegrationApp-Dev",
  "appId": "00000000-1111-2222-3333-444444444444",
  "identifierUris": ["api://dev.myapp.contoso.com"]
}

If you intended to target the production registration (TeamsIntegrationApp) but the client_id is TeamsIntegrationApp-Dev, the assignment check runs against the dev app’s policy, not prod’s. Verify the correct client_id for the environment.

Diagnostic Workflow

Step 1: Extract the AADSTS error code from the token response

RESPONSE=$(curl -s -X POST \
  "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=https://graph.microsoft.com/.default")
echo "$RESPONSE" | jq '{error, error_codes, error_description}'

Note the error_codes value: 50105 points to assignment, 53003 to CA block, 50158 to external challenge (MFA/terms of use).

Step 2: Look up the sign-in in Entra ID audit logs

curl -s -X GET \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=appId eq '$CLIENT_ID'&\$top=10&\$orderby=createdDateTime desc" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | \
  jq '.value[] | {createdDateTime, userPrincipalName, status: .status.errorCode, failureReason: .status.failureReason, appliedConditionalAccessPolicies}'

The appliedConditionalAccessPolicies array shows every policy that evaluated the sign-in and its result. This is the fastest way to identify which CA policy is blocking and why.

Step 3: For AADSTS50105 — check assignment status

SP_ID=$(az ad sp show --id $CLIENT_ID --query id -o tsv)

# Is assignment required?
curl -s "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID?$select=appRoleAssignmentRequired" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq .appRoleAssignmentRequired

# Who is currently assigned?
curl -s "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignedTo" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.value[] | {principalDisplayName, principalType}'

Step 4: For AADSTS53003 — inspect the blocking CA policy

# Get the policy ID from sign-in logs (Step 2), then inspect it
curl -s "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/$POLICY_ID" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | \
  jq '{displayName, state, conditions, grantControls, sessionControls}'

Determine whether the user/SP can satisfy the controls (MFA, compliant device, approved app) or whether an exclusion is appropriate.

Step 5: Apply the fix — assign the user/SP or adjust the CA policy

# Assign a user to the application
USER_OID=$(az ad user show --id james.joyner@contoso.com --query id -o tsv)
curl -s -X POST \
  "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignments" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"principalId\": \"$USER_OID\", \"resourceId\": \"$SP_ID\", \"appRoleId\": \"00000000-0000-0000-0000-000000000000\"}" | jq .

# Assign a group instead (preferred for bulk)
GROUP_OID=$(az ad group show --group "TeamsIntegrationUsers" --query id -o tsv)
curl -s -X POST \
  "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignments" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"principalId\": \"$GROUP_OID\", \"resourceId\": \"$SP_ID\", \"appRoleId\": \"00000000-0000-0000-0000-000000000000\"}" | jq .

For CA policy blocks, work with the security team to add the service account to a CA exclusion group, or create a named location policy that exempts automation IPs.

Example Root Cause Analysis

A Teams notification bot deployed for a new project team begins failing with AADSTS50105 for all users in the Sales department. The IT team recently restructured the enterprise application to require explicit assignment as part of a security hardening initiative.

Checking the service principal:

curl -s "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID?$select=appRoleAssignmentRequired" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq .

{ "appRoleAssignmentRequired": true }

The setting was switched to true four days ago. Checking assignments:

curl -s "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignedTo" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '[.value[].principalDisplayName]'

["IT-Operations-Group", "Engineering-All"]

Sales is not assigned. The fix is to assign the Sales-All Entra ID group to the enterprise application. After the assignment, new token requests from Sales users succeed without any application code change. The group-based approach means future Sales hires automatically inherit access through group membership.

Prevention Best Practices

• Document the appRoleAssignmentRequired setting for every enterprise application in your tenant’s app registry; treat any change to it as a potentially breaking change that requires a coordinated rollout.
• When enabling user assignment, pre-assign all required groups before flipping the flag — never flip appRoleAssignmentRequired to true without first populating the assignment list.
• Scope CA policies to named groups rather than "All Users" so service accounts and automation identities can be excluded cleanly without weakening policies for humans.
• Monitor Entra ID sign-in logs for error codes 50105 and 53003 via a Log Analytics alert — both are hard failures that block users immediately and warrant proactive notification.
• For non-interactive flows, use managed identities or dedicated service principals assigned to the app; avoid using user accounts in automation since they are more likely to be caught by MFA CA policies.
• The incident response assistant can parse AADSTS error codes and sign-in log exports to quickly map which CA policy is blocking which users during an access incident.

Quick Command Reference

# Get the service principal ID for an app registration
SP_ID=$(az ad sp show --id $CLIENT_ID --query id -o tsv)

# Check if user assignment is required
curl -s "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID?$select=appRoleAssignmentRequired" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq .appRoleAssignmentRequired

# List all current app role assignments
curl -s "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignedTo" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.value[] | {principalDisplayName, principalType, appRoleId}'

# Assign a user to the application
USER_OID=$(az ad user show --id $UPN --query id -o tsv)
curl -s -X POST "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignments" \
  -H "Authorization: Bearer $ADMIN_TOKEN" -H "Content-Type: application/json" \
  -d "{\"principalId\":\"$USER_OID\",\"resourceId\":\"$SP_ID\",\"appRoleId\":\"00000000-0000-0000-0000-000000000000\"}"

# Assign a group to the application
GROUP_OID=$(az ad group show --group "$GROUP_NAME" --query id -o tsv)
curl -s -X POST "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/appRoleAssignments" \
  -H "Authorization: Bearer $ADMIN_TOKEN" -H "Content-Type: application/json" \
  -d "{\"principalId\":\"$GROUP_OID\",\"resourceId\":\"$SP_ID\",\"appRoleId\":\"00000000-0000-0000-0000-000000000000\"}"

# Pull recent sign-in failures for an app
curl -s "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=appId eq '$CLIENT_ID' and status/errorCode ne 0&\$top=20" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | \
  jq '.value[] | {createdDateTime, userPrincipalName, errorCode: .status.errorCode, failureReason: .status.failureReason}'

# List CA policies
curl -s "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.value[] | {id, displayName, state}'

# Inspect a specific CA policy
curl -s "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/$POLICY_ID" \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '{displayName, state, conditions, grantControls}'

# Get a fresh token and verify its claims
TOKEN=$(az account get-access-token --resource https://graph.microsoft.com --query accessToken -o tsv)
echo "$TOKEN" | cut -d'.' -f2 | base64 -d 2>/dev/null | jq '{tid, oid, upn, scp, roles}'

Conclusion

AADSTS50105 and Conditional Access block errors in Teams and Graph API flows are almost always one of six root causes:

1. appRoleAssignmentRequired is true on the enterprise application but the affected user or service principal has no assignment.
2. A Conditional Access policy (AADSTS53003) blocks the sign-in because the user cannot satisfy the required controls — compliant device, approved app, or MFA.
3. A service principal used in client-credentials flows is not assigned to the application when assignment is required.
4. A CA policy requiring MFA applies to a non-interactive flow that cannot satisfy the MFA challenge (AADSTS50158).
5. Group-based assignment is configured but on-premises AD sync has not yet propagated the new group membership to Entra ID.
6. The wrong client_id is used in the token request, targeting a different app registration with different assignment and CA policy state.

Always extract the exact AADSTS error code from the token response first, then pull sign-in logs from Entra ID to identify which CA policy fired and why, before modifying assignment lists or policy exclusions. Browse more Microsoft Teams troubleshooting guides for related authentication and authorization issues.