AADSTS50020 — "User account from identity provider does not exist in tenant and cannot access the application in that tenant." The user authenticated successfully somewhere (their home tenant, or a Microsoft personal account), but the target tenant has no matching user object. It is an account-vs-tenant mismatch, not a password problem.
AADSTS50020
User account from identity provider does not exist in tenant
What it means
Common causes
The user signed in with a personal Microsoft account when the app/tenant expects a work account, or the other way round.
The app authenticates against a specific tenant (
/{tenantid}authority) but the user belongs to a different tenant and has no guest object there.The user was supposed to be a B2B guest but was never invited, or the invitation was not redeemed.
The app uses
/consumersor/organizationswhen it should use/common, or vice versa — the authority endpoint excludes the account type used.
How to fix it
Check which tenant the error names and whether the signing-in account should exist there; invite external users as B2B guests (Entra admin center > Users > New user > Invite external user) if that is the intent.
Fix the authority: multi-tenant apps that should accept any work account use
/organizationsor/common; single-tenant apps must be accessed by accounts in that tenant.Users with both personal and work accounts on the same email: pick the correct account type at the 'Which account do you want to use?' prompt, or use a private window to avoid a cached wrong account.
Frequently asked
The user exists in our directory — why AADSTS50020?
Check which tenant the request actually targeted (the error message names it) — apps hard-coded to another tenant ID, or signing in with a personal account instead of the work account, produce this even when the work user exists.