SSOGEN / Free tools / AADSTS50020: User Account Does Not Exist in Tenant

Free tool

AADSTS50020: User Account Does Not Exist in Tenant

AADSTS50020 means the account that signed in comes from an identity provider but does not exist in the tenant that owns the application. Paste the error into the reader below and it pulls out the account, the tenant and the IDs, then lists the checks. Eight causes follow, ranked, each with its fix.

Try it on your systems

Read the error

Paste the text from the sign-in page, the error_description in a redirect, or a line from the sign-in log.

The reader extracts the code, Trace ID, Correlation ID, timestamp, accounts and the IDs the message names, then lists the checks for that code.

Paste the error text

The message from the sign-in page, the error_description in a redirect, or a line from the sign-in log. It starts with AADSTS and a number.

Private by design. Reading happens in this page and nothing is sent anywhere. The text can hold email addresses, tenant names and IDs: use a copy you are allowed to look at. Real messages vary in wording; the samples are shortened.

Free, in your browser. Nothing is sent anywhere. The message can contain an email address, a tenant name and an application ID, so paste a copy you are allowed to share. The Acme samples use acme.example, a reserved example domain.

The reader also covers AADSTS50105, AADSTS90072 and AADSTS700016. For the redirect URI error, use the AADSTS50011 checker.

What AADSTS50020 is

AADSTS50020 is what Microsoft Entra ID returns when a user signs in with an account the app’s tenant does not know. The account is valid and authenticated at its own identity provider, but it is neither a member nor a guest in the tenant that owns the application. Microsoft’s error list calls it UserUnauthorized.

Cause. The account is neither a member nor a guest in the tenant that owns the application.
Fix. Add the account to that tenant, or send the user to the tenant the account belongs to.
Check. The reader above shows which applies.

What the message says

Microsoft’s error list (read 2026-10-11) gives AADSTS50020 as: “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.”

Four values in it matter:

Value in the message	What it tells you
The account	Who signed in. Check the spelling and whether it is the account the person meant to use.
The identity provider	Where that account lives. An address like `https://sts.windows.net/<id>/` is another Entra tenant; `live.com` is a personal Microsoft account.
The tenant	The tenant the request went to, which is the one that does not know the account.
The application	The app the person tried to open, by ID and name.

Microsoft’s troubleshooting article (read 2026-10-11) describes the case as a guest user from an identity provider who cannot sign in to a resource tenant.

It adds a detail the message omits: in the home tenant’s sign-in logs, an administrator sees the same failure as a “90072” entry. The user sees 50020 while the home tenant’s log may show 90072.

Causes, ranked

Microsoft lists eight causes without ranking them. This order is our judgment: causes you can confirm quickly from the message come first, rare ones last. Work down the list.

Rank	Cause	How to confirm
1	The guest was never invited	The account is not in the tenant’s user list at all.
2	Signed in to the wrong tenant or with the wrong account	The account or identity provider in the message is not the combination the person meant. A leftover browser session is the usual reason.
3	The request went to a tenant-specific address instead of `/organizations` or `/common`	The authority in the app is `login.microsoftonline.com/<your tenant>` and the app is meant for other organizations.
4	The app registration is single-tenant	The `signInAudience` in the manifest does not hold a multi-organization or personal-account value.
5	The app requires user assignment and the person is not assigned	Assignment required is Yes on the enterprise application.
6	A personal Microsoft account used to reach the admin center	The person expects a directory for a Hotmail or Outlook account.
7	A resource owner password credentials flow with a personal account	The app uses ROPC and the account is a personal one.
8	A deleted guest name re-created by the home tenant’s administrator	The guest object is older than the home tenant’s user.

1. The guest was not invited

Cause. The user is external, and the tenant has no guest object for the account.
Fix. Invite the user, following Microsoft’s quickstart for adding guest users in the Azure portal. If the user should be a full member, the error text itself says to invite them through the B2B system.
Check. After the user accepts the invitation, they sign in again.

2. The wrong tenant or the wrong account

Users arrive through a direct link to the app or through the My Apps portal, and either one starts a sign-in.

The browser may already hold a session for the wrong account: a work account when the user meant a personal guest account, or the reverse.

Compare the account and identity provider in the message with the pair the user should use. Microsoft gives two examples:

The user signed in to your tenant with their organization account instead of their home tenant.
The user signed in to live.com with a personal account other than the invited one.

Fix: sign out, then sign in again in a new private browser window or a different browser.

3. The wrong endpoint

If the app registration allows more than one organization, the sign-in request must go to a matching address.

Microsoft says that with https://login.microsoftonline.com/<YourTenantNameOrID>, users from other organizations cannot access the application unless you add them as guests in that tenant, because sign-in then runs in your tenant only.

Use the address for your app type:

App type	Sign-in address
Multitenant	`https://login.microsoftonline.com/organizations`
Multitenant and personal accounts	`https://login.microsoftonline.com/common`
Personal accounts only	`https://login.microsoftonline.com/consumers`

Set it as the Authority in the app’s code. Microsoft’s MSAL configuration page covers that setting.

4. A single-tenant app registration

A single-tenant registration does not admit users from other directories or identity providers. To check it in the Azure portal:

Search for and select App registrations, then select the registration.
Select Manifest in the sidebar and find signInAudience.
Confirm it holds one of AzureADandPersonalMicrosoftAccount, AzureADMultipleOrgs or PersonalMicrosoftAccount.

Microsoft warns that you currently cannot change signInAudience in the manifest. If the value is wrong, re-create the registration with the correct account type.

5. The app requires user assignment

Cause. Assignment required is Yes, so any user not on the allowed list gets AADSTS50020.
Check. In the Azure portal, search for and select Enterprise applications, select the application, select Properties and read Assignment required.
Fix. Assign the user directly, or through a group or dynamic group the user belongs to.
Related. The error for a signed-in user without an assignment is AADSTS50105.

6. A personal account used to reach the admin center

Cause. Signing in to the Microsoft Entra admin center with a personal Microsoft account (Outlook, Hotmail, OneDrive) places you in the Microsoft Services tenant by default, as Microsoft says. That tenant has no linked directory, and this is expected behavior.
Background. Previously, a directory was created and linked to the personal account; that no longer happens.
Fix. Create an Azure account: on the Azure account website, choose Try Azure for free and follow the instructions.
Check. This creates a tenant, and you become its Global Administrator.

7. Resource owner password credentials with a personal account

Cause. Microsoft says ROPC works only within Entra tenants, not for personal accounts, and personal accounts invited to a tenant cannot use it either.
Fix. Use the tenant-specific address https://login.microsoftonline.com/<TenantIDOrName>.

8. A deleted guest name that was re-created

Cause. A guest was deleted in the resource tenant, and the home tenant’s administrator later re-created that user name. The new home account is a different object from the old guest.
Check. Microsoft’s check is the creation date. Read createdDateTime for the guest and for the home user through Microsoft Graph, Microsoft Entra PowerShell or the Microsoft Graph PowerShell SDK. If the guest predates the home tenant’s user account, this is the cause.
Fix. Reset the guest’s redemption status. This keeps the guest object, with no delete and re-create. Microsoft says you can reset it in the Azure portal, Azure PowerShell or the Microsoft Graph API.

Fix it in the portal

The common case is a user who needs access and is not in the tenant. Work through these steps in order:

Read the account and identity provider from the error.
In the Azure portal, check whether the account is already a guest in the tenant. If not, invite it as a guest user (cause 1).
If the account is already a guest, open the enterprise application, then Properties, and check Assignment required. If it is Yes, assign the user or a group that contains the user (cause 5).
If the user is not external, check which account they used. Have them sign out and try a private window (cause 2).
If many external users fail, not just one, check the app’s signInAudience and the authority address (causes 3 and 4).

Keep the Trace ID, Correlation ID and timestamp the reader extracted.

Microsoft’s error reference asks for the correlation ID and error code when you open a support ticket.

Where this meets SSOGEN

SSOGEN can use Microsoft Entra ID as an upstream identity provider, over SAML or OpenID Connect, as described on Microsoft Entra ID SSO with SSOGEN. Two facts from that setup matter here:

Entra publishes its SAML entity ID as https://sts.windows.net/<tenant-id>/, the same shape as the identity provider value in an AADSTS50020 message.
An unassigned user gets an Entra error page before the request reaches SSOGEN, so an assignment problem appears as an Entra error, not an SSOGEN one.

SSOGEN’s Entra provider also supports a sign-in restriction: a required claim tid with your tenant ID as the only allowed value. SSOGEN turns away users from any other tenant and records the reason in the audit log.

That rule applies on the SSOGEN side and does not replace inviting a guest in Entra.

To see the exact request that failed, capture the sign-in and open it in the HAR file analyzer, or trace a SAML sign-in in the SAML tracer.

Questions people ask

How to fix error code aadsts50020?

Find out why the account is not in the tenant. Invite the person as a guest, or through B2B if they should be a member, assign them to the app if Assignment required is Yes, and use the right sign-in address. Otherwise have them sign out and sign in with an account the tenant knows.

What does the AADSTS500200 error mean and how can I fix it?

Microsoft’s error list (read 2026-10-11) has no row for AADSTS500200, so no meaning can be quoted. The nearest entries are AADSTS500207, the account type cannot be used for the resource, and AADSTS500208, the domain is not a valid login domain for the account type. Paste your full message into the reader above.

What does error code AADSTS50105 mean and how can I resolve it?

AADSTS50105 is EntitlementGrantsNotFound: the signed-in user is not assigned to a role for the app. Microsoft’s fix is to assign the user to the app. In the enterprise application, add the user or a group that contains the user under Users and groups. The full page is on AADSTS50105.

How to fix your organization has disabled this device?

Microsoft’s error list (read 2026-10-11) gives AADSTS135011 as “Device used during the authentication is disabled”, and AADSTS130007 as “The device is disabled”, with no steps. The device object belongs to your organization, so ask the administrator who manages it. It is a different error from AADSTS50020, which concerns the account.

What is the difference between AADSTS50020 and AADSTS90072?

Both say the external account does not exist in the tenant. Microsoft describes AADSTS90072 as the case where the person cannot satisfy the tenant’s multifactor requirement for that reason, and it can also come from an ImmutableID mismatch for synced users. See AADSTS90072.

Can a personal Microsoft account get AADSTS50020?

Yes. Microsoft lists three paths: using a personal account for the admin center, using one against a single-tenant app, and using one with the resource owner password credentials flow. An app that serves personal accounts must have the right audience and the /common or /consumers address.

Where to go next

If the error names the redirect URI rather than the account, read AADSTS50011.
To connect Entra ID to SSOGEN, see Microsoft Entra ID SSO with SSOGEN.
More utilities are on the free tools page.

Sources, all read 2026-10-11: Microsoft Learn, Error AADSTS50020 - User account from identity provider does not exist in tenant and Microsoft Entra authentication and authorization error codes. SSOGEN facts from Microsoft Entra ID SSO with SSOGEN.

Microsoft and Entra are trademarks of their owner; SSOGEN is not affiliated with Microsoft.