AADSTS50020 - User Not In Tenant
Azure AADSTS50020 is a directory boundary error. It occurs when a valid user attempts to sign in to an application, but their account does not exist as a member or invited guest in the specific Microsoft Entra tenant hosting the app.
Last reviewed: April 5, 2026|Editorial standard: source-backed technical guidance
What Does User Not In Tenant Mean?
AADSTS50020 is Entra ID’s way of saying: "Your credentials are valid, but you do not have a record in this specific directory." Even if the user is successfully authenticated in their home tenant, the resource tenant (where the app lives) does not recognize them as a member or a guest. This is common in single-tenant configurations or when using the wrong login endpoint.
Common Causes
- -Missing Guest Invitation: An external partner has not been invited to the resource tenant as a guest user.
- -Single-Tenant Restriction: The app is configured for my organization only, but an external user is trying to log in.
- -Wrong Endpoint Selection: The app is multitenant but the login URL uses a specific
tenant-idinstead of/commonor/organizations. - -Account Type Mismatch: A personal Outlook or Hotmail account is trying to access an app that only accepts work or school accounts.
- -Browser Session Ghosting: An old session from a different tenant is forcing the user into the wrong directory context.
How to Fix User Not In Tenant
- 1Invite the User: Go to Entra ID > Users and add the external person as a new guest user.
- 2Change App Audience: Update the app registration to multitenant under the Authentication blade.
- 3Use the Global Endpoint: Change your authority URL to
https://login.microsoftonline.com/commonto allow all account types. - 4Use Incognito Mode: Try signing in via a private window to clear any cached tenant-specific session data.
Step-by-Step Diagnosis for User Not In Tenant
- 1Check the error message for the specific account and tenant ID involved in the collision.
- 2Verify if the user exists in the target tenant’s all users list.
- 3Check the
signInAudiencein the app manifest (AzureADMyOrgvsAzureADMultipleOrgs). - 4Inspect the
tid(tenant ID) parameter in the authentication request.
Home Tenant vs. Resource Tenant
- -Home Tenant: Where the user’s account actually lives.
- -Resource Tenant: Where the application lives. The user must be a member or guest here.
Implementation Examples
// Wrong (single-tenant lock):
const authority = "https://login.microsoftonline.com/YOUR_TENANT_ID";
// Right (allows all organizational accounts):
const authority = "https://login.microsoftonline.com/organizations";How to Verify the Fix
- -Ensure the user accepts the B2B invitation email before retrying.
- -Confirm that a user from a different organization can now receive an ID token.
- -Verify that the result in Entra sign-in logs has changed to success.
How to Prevent Recurrence
- -Automate Onboarding: Use Entitlement Management to automate guest invitations for partners.
- -Standardize Endpoints: Decide early if your app is single- or multi-tenant and lock the authority URLs accordingly.
- -Pro-tip: For multitenant apps, always validate the
tidclaim after login to block unauthorized organizations at the application level.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.