AADSTS50020: Account from identity provider not in tenant

What does AADSTS50020 mean?

UserUnauthorized: Users are unauthorized to call this endpoint. User account ‘{email}’ from identity provider ‘{idp}’ does not exist in tenant ‘{tenant}’ and cannot access the application ‘{appid}’({appName}) in that tenant. This account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Microsoft Entra user account. If this user should be a member of the tenant, they should be invited via the B2B system.

Is it an attack?

Usually not. Microsoft’s troubleshooting article lists these causes:

• A personal Microsoft account used to sign in to an admin portal.
• A single-tenant app (signInAudience) being used by accounts from another tenant.
• The app sends users to the wrong authority endpoint (/common versus a specific tenant).
• The user is signed in to the wrong tenant in the browser.
• The external user was never invited as a guest.
• The app requires assignment.
• ROPC (username/password flow) used with personal accounts.
• The user was deleted and re-created in their home tenant, which leaves the old guest object in your tenant orphaned.

Pattern	Likely meaning
A partner user, first time on an app	Not invited yet, or wrong tenant in the link. Benign.
A known guest who used to work, now fails	Orphaned guest. Their home account was re-created. Lifecycle cleanup, not an attack.
Your own staff on a partner’s app	Wrong authority or single-tenant app on the partner side. Benign.
Many different external identities you never invited, against one or several of your apps	Someone checking which of your apps accept outside accounts. Investigate.

The last row is our reasoning, not a Microsoft statement. Microsoft documents 50020 as a configuration error. The orphaned-guest case is the more useful finding for most tenants: it shows guest objects whose real-world identity no longer matches.

How do I find it in my logs (KQL)?

Which external identities hit 50020, against which apps:

SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == "50020"
| summarize Attempts = count(),
            Apps = make_set(AppDisplayName, 10),
            IPs = make_set(IPAddress, 10),
            HomeTenants = make_set(HomeTenantId, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by UserPrincipalName
| sort by Attempts desc

Possible probing: one IP, many distinct external identities:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50020"
| summarize Identities = dcount(UserPrincipalName),
            Apps = make_set(AppDisplayName, 10),
            Attempts = count()
          by IPAddress
| where Identities >= 5
| sort by Identities desc

The UserPrincipalName on a 50020 row is the identity that tried to sign in, which by definition isn’t a user in your tenant. Check one row in your workspace to see how it is filled before you rely on it; the email in the error message may be hidden or differ. The threshold of 5 is a starting point, not a tested value.

To find orphaned guests, compare the identities above with your guest list. A guest whose email matches a 50020 identity existed in your tenant but no longer matches its home account.

How does Conditional Access affect it?

• 50020 is not a Conditional Access result. The account isn’t in your tenant, so there is no user for your policies to evaluate.
• Once the external user is invited and redeems the invitation, your policies for guests and external users apply to them like any other sign-in. Have those guest policies in place before you invite.
• Cross-tenant access settings decide which outside organisations can collaborate at all. They are the place to limit B2B access, not exclusions in individual apps.

How do I fix AADSTS50020?

For the user: sign out, then sign in again with the account your organisation gave you. If you are a partner, ask your contact to invite you as a guest.

For admins and developers:

1. Check the tenant and app in the error. If the user should have access, invite them via B2B.
2. For an orphaned guest (home account re-created), remove the old guest object and invite again. Microsoft’s article covers this case.
3. For your own app: check signInAudience and the authority URL. A multi-tenant app shouldn’t send users to a single tenant’s endpoint, and a single-tenant app shouldn’t be offered to outside users.
4. Review guest accounts on a schedule. Orphaned guests are inactive objects with access rights that nobody uses.