AADSTS50020

User account is from a different identity provider

Answer: The account used for sign-in does not exist in the tenant where the application is registered and cannot access the application there.

Resolution playbook

Fix it, then prove it

Use the error record as the starting point; use tenant evidence to confirm the actual cause.

This is commonly a tenant-selection problem rather than a bad password.
Conditional Access, MFA, identity risk, session, tenant routing, or account state changed the authentication decision.
The sign-in used a different application, resource, device, location, or authentication flow than the working comparison.

Confirm the authority and tenant ID used by the application.
Invite the external identity when guest access is intended.
Sign out cached accounts and select the identity associated with the target tenant.

Repeat the sign-in using the intended tenant and supported interactive or non-interactive flow.
In Entra sign-in logs, confirm the new event succeeds and review Authentication Details and Conditional Access tabs.
If a policy was changed, confirm the expected policy result using report-only or What If before broad rollout.

The failure persists after the documented prerequisites and a new authentication/session attempt.
Multiple users, apps, devices, or networks show the same error, suggesting tenant policy or service scope.
You can provide the exact UTC time, tenant, application/resource, correlation or request ID, and sanitized logs.

Capture the support evidence

Error code: AADSTS50020
UTC timestamp: <yyyy-mm-dd hh:mm:ssZ>
Correlation ID: <guid>
Tenant ID: <guid>
Application / resource: <name>

Template only. Fill it from the failed sign-in and keep user identifiers out of public tickets.

This is commonly a tenant-selection problem rather than a bad password.