# Fix Microsoft AADSTS cross-tenant errors

Source: https://developer.nylas.com/docs/cookbook/use-cases/build/fix-aadsts-cross-tenant/

A user from a different company tries to connect their Microsoft 365 account, and the sign-in screen rejects them with a message that their account `does not exist in tenant`. Their credentials are valid and they signed in correctly, yet Microsoft Entra won't let them reach your Azure app. The culprit is almost always your app registration's account-type setting. It isn't a problem with the user's account.

These cross-tenant failures surface as `AADSTS90072`, `AADSTS50020`, or `AADSTS700016` and trace to two settings: your Azure app's `signInAudience` value and the authority URL the request targets. A single-tenant registration only accepts users from your own directory, so anyone from an outside organization gets blocked. This page maps each cross-tenant code to its cause and fix. For consent-related blocks, see [fix the need admin approval error](/docs/cookbook/use-cases/build/fix-admin-approval-error/).

## What causes AADSTS90072 and AADSTS50020?

Both codes mean the signed-in account lives in a different Microsoft Entra directory than the one your Azure app trusts. Microsoft returns `AADSTS50020` when a user from an external identity provider hits a single-tenant app, and `AADSTS90072` when a guest account exists but isn't authorized for the application. The root cause is the app's `signInAudience` value.

Microsoft states `AADSTS50020` verbatim as `User account '{email}' from identity provider '{idp}' does not exist in tenant '{tenant}' and cannot access the application '{appid}'({appName}) in that tenant.` A single-tenant app has `signInAudience` set to `AzureADMyOrg`, which accepts 0 users from outside your own directory. When someone from another company signs in, Entra finds no matching account in your tenant and stops them at the sign-in page before any code reaches your callback.

## Single-tenant vs multi-tenant app registration

The `signInAudience` field controls which directories your Azure app accepts, and it's the single setting that decides whether cross-tenant users can connect. A single-tenant app accepts users from 1 directory only. A multi-tenant app accepts users from any organization on Microsoft Entra, which is what you want when your users come from many different companies.

Microsoft exposes 4 account-type values for this field, shown on the **Supported account types** screen during registration and as `signInAudience` in the app manifest. Pick the one that matches who connects to your integration. If even 1 user comes from outside your own company, you need a multi-tenant value, not the single-tenant default.

| Supported account types | `signInAudience` | Who can connect |
| --- | --- | --- |
| This organizational directory only | `AzureADMyOrg` | Only users in your own tenant |
| Any organizational directory (multitenant) | `AzureADMultipleOrgs` | Work or school accounts from any tenant |
| Any directory + personal accounts | `AzureADandPersonalMicrosoftAccount` | Work, school, and personal Microsoft accounts |
| Personal accounts only | `PersonalMicrosoftAccount` | Only `outlook.com` and `hotmail.com` accounts |

## How do I change signInAudience in the Entra admin center?

Change the account type in the [Microsoft Entra admin center](https://entra.microsoft.com) under your app registration's **Authentication** pane. Select **Supported account types**, then switch from **Accounts in this organizational directory only** to **Accounts in any organizational directory**. That flips `signInAudience` from `AzureADMyOrg` to `AzureADMultipleOrgs` in 1 step.

Microsoft creates every web app and API registration as single-tenant by default, so a new app starts at `AzureADMyOrg` until you change it. Follow these steps:

1. Sign in to the Entra admin center and open **Identity** > **Applications** > **App registrations**, then select your app.
2. Open the **Authentication** pane and find the **Supported account types** section.
3. Select **Accounts in any organizational directory** to set `signInAudience` to `AzureADMultipleOrgs`, then **Save**.
4. Confirm your **Application ID URI** on the **Overview** page follows the `https://{tenant}.onmicrosoft.com/{app}` pattern. Microsoft requires this URI to be globally unique across all tenants for a multi-tenant app, and the switch fails if it doesn't match the expected format.

After the switch, the first user from each new tenant sees a consent prompt, and an admin may need to approve it under that tenant's policy. They then restart the hosted flow at `GET /v3/connect/auth` and the grant returns normally. See [creating an Azure auth app](/docs/provider-guides/microsoft/create-azure-app/) for the full registration walkthrough.

## Which authority URL fixes AADSTS700016 and AADSTS50194?

The authority URL in your auth request decides which directory Entra searches for the user, and the wrong one produces `AADSTS700016` or `AADSTS50194`. A multi-tenant app must send users to `/common` or `/organizations`, not a hardcoded tenant ID. Microsoft returns `AADSTS700016` when it looks for your app in the wrong directory and `AADSTS50194` when a single-tenant app calls `/common`.

Microsoft offers 3 authority forms: `https://login.microsoftonline.com/common` accepts any work, school, or personal account; `https://login.microsoftonline.com/organizations` accepts any Microsoft Entra organization but no personal accounts; and `https://login.microsoftonline.com/{tenant-id}` restricts sign-in to one named directory. If you hardcode a tenant ID for an app meant to serve many companies, every user outside that one directory hits `AADSTS700016`, which Microsoft describes as `The application wasn't found in the directory/tenant.` Flip the relationship and `AADSTS50194` appears: a single-tenant app that calls `/common` is told it `isn't configured as a multitenant application` and that `Usage of the /common endpoint isn't supported`.

A third code rounds out the set. `AADSTS50128` is `Invalid domain name` and means `No tenant-identifying information found in either the request or implied by any provided credentials`, which happens when the authority lacks a tenant segment and Entra can't resolve a directory at all.

| Error code | Cause | Fix |
| --- | --- | --- |
| `AADSTS50020` | Single-tenant app (`AzureADMyOrg`) rejects a user from another directory | Switch the app to `AzureADMultipleOrgs` (multitenant) |
| `AADSTS90072` | User exists as a guest but isn't authorized for this app in the tenant | Invite or authorize the guest account, or use a multi-tenant app |
| `AADSTS700016` | Auth request hit the wrong tenant, or the app isn't in that directory | Send the request to `/common` or `/organizations`, not a hardcoded tenant ID |
| `AADSTS50128` | Invalid domain name: no tenant-identifying information in the request | Use a valid authority such as `/common`, `/organizations`, or a tenant ID |
| `AADSTS50194` | Single-tenant app called the `/common` endpoint | Convert the app to multi-tenant, or call a tenant-specific endpoint |

## What about guest accounts and B2B collaboration?

A guest account is an external user invited into a tenant through Microsoft Entra B2B collaboration, and it can still hit `AADSTS90072` if your app doesn't trust that directory. The guest signs in with their home-tenant credentials, so Entra evaluates the request against the resource tenant's policy. A single-tenant app trusts 1 directory, so if the guest's home directory isn't your tenant, the request fails. Microsoft describes `AADSTS90072` as the case where `The external account that the user signs in with doesn't exist on the tenant that they signed into`.

For most integrations you don't manage guest invitations directly. Make the app multi-tenant and let each user consent from their own organization, which avoids guest provisioning entirely. Microsoft's external identities model treats each consenting tenant as a separate directory, so 1 multi-tenant app can serve hundreds of organizations without inviting a single guest. If you only need to reach a single company with application permissions, a [Microsoft bulk authentication grant](/docs/v3/auth/bulk-auth-grants/#create-microsoft-bulk-authentication-grants) lets an admin consent once to cover 100% of users in that tenant instead of per user.

## Why does multi-tenant require publisher verification?

Flipping an app to multi-tenant changes who can consent to it, and Microsoft's risk-based step-up consent policy blocks most unverified multi-tenant apps at the consent screen. Publisher verification adds a blue badge to the consent prompt and signals that a real organization owns the app. Without it, external admins often have to approve your app manually before any of their users connect.

Microsoft introduced this rule in November 2020: when risk-based step-up consent is enabled, users can't consent to most newly registered multi-tenant applications that haven't been verified. The consent page warns that the app is risky because it comes from an unverified publisher, which slows or blocks adoption across customer tenants. Verification is free, takes minutes once you meet the requirements, and needs no special license. Nylas connectors inherit whatever account type and verification state your Azure app carries, so completing it once benefits every tenant you onboard. Walk through the steps in the [Microsoft publisher verification guide](/docs/provider-guides/microsoft/verification-guide/).

## How do Nylas connectors fit into the fix?

The Azure app you register owns the cross-tenant behavior, and the Nylas Microsoft connector carries that app's client ID, secret, and a `tenant` setting. The connector's `tenant` field maps directly to the authority segment in the auth request, so setting it to `common` routes sign-ins through the `/common` endpoint that multi-tenant apps require. You change the account type in Azure, then make sure the connector's `tenant` matches.

In practice the fix lives in two places. In Entra you set **Supported account types** to a multi-tenant value. In Nylas you create or edit the Microsoft connector and set its **Azure tenant** to `common`, either in the Dashboard or by passing `"tenant": "common"` in the [Create Connector request](/docs/reference/api/connectors-integrations/create_connector/) `settings` object. A connector still pointing at a single tenant ID keeps rejecting outside users even after you switch the Azure app, so both ends must agree. Picture a scheduling SaaS onboarding 300 customer companies: 1 multi-tenant Azure app plus 1 connector with `tenant: "common"` lets every customer's admin consent independently, and each connected mailbox returns its own grant with no per-tenant app registration.

## What's next

- [Fix the need admin approval error](/docs/cookbook/use-cases/build/fix-admin-approval-error/) for `AADSTS65001` and tenant consent policy
- [Troubleshoot OAuth errors](/docs/cookbook/use-cases/build/troubleshoot-oauth-errors/) for `redirect_uri` mismatch (`AADSTS50011`), `access_denied`, and expired grants
- [Microsoft publisher verification guide](/docs/provider-guides/microsoft/verification-guide/) to earn the blue consent badge for a multi-tenant app
- [Creating an Azure auth app](/docs/provider-guides/microsoft/create-azure-app/) to register the app and set its account type