AADSTS500208 Error when user tries to login, I am using Microsoft Entra ID (Azure AD) with MSAL authentication for my web application.

1. Reason personal Microsoft accounts fail as guests

For mixed account types, the sign‑in endpoint and app’s supported account type must match the account being used:

• If the app registration is effectively single‑tenant or tied to a specific tenant endpoint like https://login.microsoftonline.com/<YourTenantNameOrID>, external users (including personal Microsoft accounts) cannot sign in directly and must exist as guests in that tenant.
• For personal Microsoft accounts to sign in as guests, the app must be configured to support them and the correct “common/consumers/organizations” endpoints must be used.

If the wrong endpoint is used for the account type, Entra ID will reject the sign‑in. This is the same pattern as described for AADSTS50020 when the endpoint does not match the supported account types. For example, using a tenant‑specific authority instead of organizations, common, or consumers for an app that should accept personal accounts.

2. Reliability of GetCredentialType for onboarding decisions

GetCredentialType is not the supported mechanism for deciding how to onboard users (guest vs local account). It is an internal credential‑discovery endpoint and not documented as an official decision point for B2B/B2C/CIAM onboarding logic.

The supported way to control who can sign in is:

• Configure the app registration’s signInAudience (supported account types) correctly.
• Use the correct sign‑in authority URL in MSAL that matches that audience (for example organizations, common, or consumers as appropriate).
• For B2B guests, ensure the user exists as a guest in the tenant and that cross‑tenant access settings allow the sign‑in.

3. Cause of AADSTS500208 for an invited organizational guest

From the External ID federation FAQ:

AADSTS500208: The domain is not a valid login domain for the account type means sign‑in failed because the account type isn’t permitted to use the login URL or tenant being accessed. The fix is to verify that the correct sign‑in endpoint is being used and that the account has access to the target tenant.

Applied to the described scenario:

• The user is an organizational account invited as a guest.
• The app or MSAL is likely using an authority URL that does not match the account type or tenant context (for example, a CIAM authority or tenant‑specific authority that does not accept that domain/account type for that app configuration).
• This mismatch between:
  • app’s signInAudience,
  • the authority URL used in MSAL, and
  • the user’s account type/domain
  leads to AADSTS500208.

4. Configuration gaps in Entra ID / MSAL / CIAM authority

Based on the documented patterns, typical configuration issues that cause these symptoms are:

• signInAudience not aligned with actual usage
  • If the app is effectively single‑tenant, external users cannot sign in. The fix in the general case is to ensure signInAudience is one of:
    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount
  • If it is not, the app registration must be recreated with the correct supported account type.
• Wrong authority URL for the account type
  • For multitenant organizational accounts: use https://login.microsoftonline.com/organizations.
  • For multitenant + personal accounts: use https://login.microsoftonline.com/common.
  • For personal accounts only: use https://login.microsoftonline.com/consumers.
  • Using a tenant‑specific authority (…/<tenantId>) when expecting external org or personal accounts will block those accounts and can surface as AADSTS50020/500208.
• External ID / federation configuration
  • When using External ID federation (for example, adding another Entra tenant as an OIDC IdP), if the issuer URI or discovery endpoints are misconfigured, the IdP will not appear or tokens will be rejected.
  • Error 40015 is raised when the external IdP configuration or returned tokens cannot be validated (issuer mismatch, wrong endpoints, missing required claims like subject or email).

5. Recommended approach for mixed personal + organizational accounts

The documented, supported patterns for mixed account types are:

• Use an app registration whose signInAudience supports the desired mix:
  • AzureADandPersonalMicrosoftAccount for both organizational and personal Microsoft accounts.
• Use the corresponding sign‑in URL in MSAL:
  • For multitenant + personal accounts: https://login.microsoftonline.com/common.
• For B2B guests (organizational accounts from other tenants):
  • Invite them as guests in the resource tenant.
  • Ensure cross‑tenant access settings allow invitations and sign‑ins.
• For External ID federation with Entra ID as an OIDC IdP:
  • Ensure issuer URI, discovery endpoint, redirect URIs, and scopes are correctly configured.
  • Add the IdP to the user flow, not just to the tenant.

In this model there is no need to call GetCredentialType to decide guest vs local account. Instead, rely on:

• Correct app registration audience (signInAudience).
• Correct authority URL (organizations/common/consumers) in MSAL.
• Standard B2B guest invitations and External ID configuration.

Aligning the app’s supported account types with the correct authority URL and ensuring guests are properly provisioned in the tenant is the supported way to handle mixed personal and organizational Microsoft accounts and will prevent AADSTS500208 and related sign‑in errors.

References:

• Error AADSTS50020 - User account from identity provider does not exist in tenant
• Add a Microsoft Entra ID tenant as an OpenID Connect identity provider (Preview)
• Troubleshoot common issues with Microsoft Entra B2B collaboration