AADSTS50020 is the sign-in error Microsoft Entra ID returns when the account that has just authenticated does not exist in the tenant the request was sent to. Inviting the user again is the usual reflex, and it often changes nothing, because Microsoft Learn lists eight separate causes and only one of them is a missing invitation. This post separates the eight by what the error message and the sign-in log actually show, and gives the fix for each.
It is a spoke of the AADSTS error codes hub, grouped by cause, which itself sits under the Conditional Access and sign-in policy guide. Every Microsoft fact below was checked against Microsoft Learn on 31 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices and no partner tenants, so what follows is the documentation read carefully, plus where I would expect it to bite.
What the AADSTS50020 message is telling you
The full message reads: AADSTS50020: User account 'user@domain.com' from identity provider {IdentityProviderURL} does not exist in tenant {ResourceTenantName}. Three values in it do most of the work: the user account, the identity provider and the tenant. Before changing anything, check whether that combination is the one you expected. A user who signed in with their work account when they were invited with a personal one, or the reverse, produces exactly this error, and no setting in either tenant will fix it.
There is a second half that most guides leave out. According to Microsoft’s troubleshooting article for error AADSTS50020, when an administrator reviews the sign-in logs in the user’s home tenant, the same failure is recorded as error code 90072, with a message saying the account needs to be added as an external user in the tenant first. So the user sees AADSTS50020 and the home tenant’s log shows 90072. If you administer the home tenant and a user reports AADSTS50020, search your logs for 90072.
The eight causes of AADSTS50020 and the first check for each
The Learn article lists the causes in this order. The middle column is the quickest way I know to tell them apart from the error message, the sign-in log or the app registration.
| Cause | What gives it away | Fix |
|---|---|---|
| 1. Personal Microsoft account used to sign in to the Entra admin center | An Outlook, Hotmail or OneDrive account and no directory of your own | Expected behaviour. Create an Azure account, which creates a tenant |
| 2. App registration is single-tenant | signInAudience is not one of the multitenant or personal account values | Re-create the registration with the right supported account type |
| 3. Wrong authority endpoint | The app signs in against a tenant-specific URL but expects users from other organisations | Use the organisations, common or consumers endpoint that matches the account type |
| 4. Signed in with the wrong account | The account or identity provider in the message is not the one that was invited | Sign out and retry in a private browser session or another browser |
| 5. Guest was never invited | No guest object for that address in the resource tenant | Invite the user |
| 6. Assignment required on the enterprise application | Assignment required is set to Yes and the user is not assigned | Assign the user directly or through a group |
| 7. Resource owner password credentials (ROPC) with a personal account | A script or legacy client sending a password grant | Use a tenant-specific or organisations endpoint; personal accounts cannot use ROPC |
| 8. Home account deleted and re-created | The guest object is older than the account in the home tenant | Reset the guest’s redemption status |
Causes 4, 5 and 8 are the ones an administrator meets with real users. Causes 2, 3 and 7 are developer problems that reach the administrator as a support ticket. Cause 1 is someone trying to use a personal account as a lab, and cause 6 is a setting that has nothing to do with the tenant boundary at all.
Guest accounts: never invited, or invited as someone who no longer exists
Cause 5 is the obvious one: the person was never invited, so there is no guest object, and inviting them fixes it. Cause 8 is the one that wastes an afternoon. The guest object exists and looks healthy, but the home tenant’s administrator has deleted the user and created a new account with the same name. The guest in the resource tenant is still tied to the old account, which no longer exists, so the new account signs in successfully at home and then fails with AADSTS50020 in your tenant.
Microsoft’s test is to compare creation dates. If the guest object in the resource tenant was created before the user account in the home tenant, the home account has been re-created. The Learn article gives Microsoft Graph, Microsoft Entra PowerShell and Microsoft Graph PowerShell SDK versions of the same read; this is the SDK one.
# Read CreatedDateTime for the guest (in the resource tenant) or the account (in the home tenant).
# Run once in each tenant and compare: a guest older than the home account means the account was re-created.
$p = @('Id', 'UserPrincipalName', 'CreatedDateTime')
Get-MgUser -UserId 'object-id-or-upn' -Property $p | Select-Object $p
You need the home tenant’s half of that answer, which usually means asking the partner’s administrator. That conversation is worth having before you touch the guest object.
The fix is to reset the guest’s redemption status rather than delete the guest. Microsoft Learn says this keeps the user’s object ID, group memberships and app assignments; the user redeems a new invitation, the user principal name stays the same, and the sign-in name changes to the new email. It needs Helpdesk Administrator (the least privileged role Learn lists) or User Administrator. In the admin center the path is Entra ID, Users, the user’s profile, then on the Overview tab under My Feed, the Reset redemption status link in the B2B collaboration tile. From PowerShell it is New-MgInvitation with the -ResetRedemption switch. One catch from the same page: for app-only calls, the redemption status cannot be reset if any roles are assigned to the target user account.
The newsletter
Get the next Entra ID fix like this one by email
Subscribe and get the free 8-page Intune troubleshooting field guide (PDF), then new fixes about twice a month. From a Microsoft MVP.
App registrations and the wrong authority
The Stack Overflow questions that rank for AADSTS50020 are mostly this group, and they usually come down to cause 2 or cause 3.
Cause 2 is a single-tenant app registration. Users from other directories or identity providers cannot sign in to it. The Learn article sends you to the manifest to check signInAudience for one of AzureADMultipleOrgs, AzureADandPersonalMicrosoftAccount or PersonalMicrosoftAccount, and it states that you currently cannot change signInAudience in the manifest. If the value is wrong, the registration has to be re-created with the right account type selected. That makes the supported account type a decision to get right on day one, not a setting to fix later.
Cause 3 is an app registered correctly as multitenant that still authenticates against login.microsoftonline.com/{tenant}. With a tenant-specific authority, users from other organisations can only sign in if they are guests in that tenant. The Authority setting has to match the account type:
| Application type | Sign-in URL |
|---|---|
| Multitenant | login.microsoftonline.com/organizations |
| Multitenant and personal accounts | login.microsoftonline.com/common |
| Personal accounts only | login.microsoftonline.com/consumers |
Cause 7 runs the other way. The Microsoft identity platform supports ROPC only within Entra tenants, not for personal accounts, and personal accounts invited into a tenant cannot use it either. A script that posts a username and password for a personal account will get AADSTS50020 whatever endpoint it uses.
Assignment required, the cause nobody expects
If an enterprise application has Assignment required set to Yes, the Learn article lists AADSTS50020 as the result for a user who is not on the list of assigned users. Check it under Enterprise applications, the app, Properties. The fix is to assign the user individually or through an assigned or dynamic group.
This overlaps with AADSTS50105, which the error codes reference describes as a signed-in user who is not assigned to a role for the application. Which of the two a guest actually sees is something I would confirm in the sign-in log rather than assume. Either way, the setting to look at is the same.
The failure modes
- Deleting and re-inviting the guest. The reset redemption page notes this used to be the only route. It works, but the new object has a new object ID and none of the old group memberships or app assignments. Resetting redemption keeps all three.
- Searching the wrong log. The home tenant records 90072, not 50020. An administrator who filters for 50020 at home finds nothing and concludes the problem is on the other side.
- Trying to edit
signInAudience. Learn says it cannot currently be changed in the manifest. Time spent there is time not spent re-creating the registration. - Retrying in the same browser. Cause 4 survives every retry while the existing session is still signed in with the other account. A private session is the test.
- Blaming cross-tenant access settings. AADSTS50020 is a missing or mismatched object. How inbound trust settings decide which partner claims you accept is a different question, with different codes.
What I would do differently
I would make the account and identity provider in the error message the first triage question, before anyone opens the guest object. Most of the eight causes are visible from those values and a glance at the app registration.
I would reset redemption status as the default repair for any guest that looks healthy but fails, and keep deletion for guests who genuinely should not exist. Losing app assignments to fix a sign-in error creates the next ticket.
For in-house apps, I would decide the supported account type in the design review, because the manifest will not let you change it later.
And if the home tenant syncs from Active Directory, I would ask whether the account was deleted and re-created on premises. I would expect that to produce cause 8 just as surely as a cloud-only re-creation, and how Cloud Sync and Connect Sync match users decides whether the cloud object survives.
The eight causes and their verification steps are in Microsoft Learn’s AADSTS50020 troubleshooting article. Use it for the procedure, and the sign-in log to find out which cause you have.
Last verified: 31 October 2026.
