Share via

AADSTS50020 in Cross-Tenant Azure AD SSO with SharePoint Access

Tejaswini Bayya 0 Reputation points
2026-04-27T14:13:39.5266667+00:00

I’m implementing Azure AD SSO across two tenants:

  • Tenant A: Contains user accounts
  • Tenant B: Contains the app registration and SharePoint resources

When users from Tenant A try to sign in to the app in Tenant B (via OAuth/MSAL), they get:

AADSTS50020: User account does not exist in tenant and cannot access the application.

Setup:

  • App registration exists only in Tenant B
  • Currently configured as single-tenant
  • Authentication flow is standard Azure AD OAuth (Authorization Code flow)

Requirements:

  • Users from Tenant A should be able to sign in (SSO) to the app in Tenant B
  • After login, they should be able to access SharePoint resources in Tenant B

Questions:

  1. Is setting the app registration in Tenant B to multi-tenant sufficient to allow cross-tenant authentication?
  2. For SharePoint access, is adding users from Tenant A as B2B guest users in Tenant B mandatory?
  3. Are cross-tenant access settings required on both tenants for this scenario?
  4. What is the recommended architecture: multi-tenant app only vs multi-tenant + guest users?

Looking for best practices to handle both authentication and SharePoint authorization in this cross-tenant setup.

Thanks!

Microsoft Security | Microsoft Entra | Microsoft Entra ID

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Shubham Sharma 17,425 Reputation points Microsoft External Staff Moderator
    2026-04-27T14:21:01.2933333+00:00

    Hello Tejaswini Bayya

    Thank you for reaching out to Microsoft Q&A.

    Based on your description, it appears that you are trying to login with Microsoft personal account, not an Azure work or school account. This is why you’re encountering errors when trying to access the Azure Portal.

    Issue: When users try to login to Azure portal using their personal Microsoft Account (Outlook, Hotmail..) they are getting AADSTS160021 or AADSTS16000 or AADSTS50020 errors.

    Reason: When signing in to the Azure portal with a personal Microsoft account, you are automatically connected to the Microsoft Services tenant (Tenant ID: f8cdef31-a31e-4b4a-93e4-5f571e91255a).

    You can verify this by navigating to Microsoft Entra ID > Overview, where you’ll see this Tenant ID.

    This default tenant does not have a directory associated with it, which you can confirm by going to the Settings blade. As a result, you cannot perform administrative actions such as:

    • Creating users or groups
    • Registering enterprise applications
    • Managing resources

    In short, it’s a system tenant with restricted capabilities, and administrative access is not granted by default.User's image

    Solution: To fully utilize the Azure portal, you need to create your own tenant instead of relying on the Microsoft Services tenant.

    Follow these steps:

    1. Open an in-private/incognito browser window (to avoid automatic sign-in via SSO).
    2. Navigate to https://azure.microsoft.com/en-us/free/ to sign up for a free Azure account.
    3. During the setup, you’ll be prompted to create a new directory (tenant). Once completed, you will become the Global Administrator of this new tenant, giving you full access to manage Azure resources.

    User's image

    Thank you

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-04-27T14:13:57.3+00:00
    1. Changing the app registration in Tenant B from single-tenant to multi-tenant is required but not sufficient by itself.

    From the AADSTS50020 guidance:

    • If the app is single-tenant, “users from other directories or identity providers can't sign in to that application.”
    • To support users from another tenant, the app registration must have signInAudience set to one of:
      • AzureADMultipleOrgs (multitenant)
      • AzureADandPersonalMicrosoftAccount

    Because signInAudience cannot be edited directly, the app may need to be re-created with the correct account type if it is currently single-tenant.

    Additionally, the correct authority/sign-in URL must be used for multitenant apps. For multitenant organizational accounts, the authority should be:

    • https://login.microsoftonline.com/organizations

    If the authority is set to a specific tenant (for example https://login.microsoftonline.com/<TenantBId>), users from Tenant A will still hit AADSTS50020 unless they are added as guests.

    1. For SharePoint access in Tenant B, adding users from Tenant A as B2B guest users in Tenant B is effectively required with the current SharePoint behavior described.

    For SharePoint Online:

    • When a site, list, or library is shared with guests, recent changes mean “the guest account isn't provisioned in Microsoft Entra ID. Therefore, guest access to the resource is blocked by the Conditional Access policies.”
    • The documented resolutions are:
      1. Enable SharePoint integration with Microsoft Entra B2B, or
      2. Explicitly add the guest user to the directory.

    In practice, this means users from Tenant A must exist as external (B2B) users in Tenant B’s Entra ID if they are to be authorized to SharePoint resources in Tenant B, especially when Conditional Access is in play.

    So, even if the app is multitenant for authentication, SharePoint authorization in Tenant B is best handled via B2B guest accounts (or via the SharePoint–Entra B2B integration that provisions them).

    1. Cross-tenant access settings are not explicitly covered in the provided context, but the key points that are covered are:
    • AADSTS50020 occurs when the user account “does not exist in the tenant” or the app is single-tenant or using the wrong authority.
    • For cross-tenant access to an app:
      • The app must be multitenant, and
      • The correct multitenant authority (organizations or common) must be used.
    • For SharePoint access:
      • The user must be added as an external user (guest) or SharePoint must be integrated with Entra B2B so that the guest account is provisioned.

    Based on this, the critical configuration items in this scenario are the app’s sign-in audience, the authority URL, and B2B guest provisioning for SharePoint. Cross-tenant access settings beyond that are not described in the context.

    1. Recommended architecture from the provided material:

    For the application (authentication):

    • Use a multitenant app registration in Tenant B (AzureADMultipleOrgs or AzureADandPersonalMicrosoftAccount).
    • Use a multitenant authority such as https://login.microsoftonline.com/organizations or https://login.microsoftonline.com/common as appropriate for the chosen sign-in audience.
    • Ensure the client (e.g., MSAL) is configured with that authority so users from Tenant A can authenticate without being pre-created as users in Tenant B.

    For SharePoint (authorization):

    • Treat SharePoint access as tenant-B resource access that requires a user object in Tenant B.
    • Use Microsoft Entra B2B for Tenant A users:
      • Either enable SharePoint integration with Entra B2B so invitations provision guest accounts, or
      • Explicitly add Tenant A users as guest users in Tenant B before sharing SharePoint resources.

    This results in a combined model:

    • Multitenant app for authentication and consent.
    • B2B guest users in Tenant B for SharePoint authorization and Conditional Access compliance.

    This aligns with the documented patterns for multitenant apps and for SharePoint guest access with Conditional Access.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.