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.
What causes AADSTS90072 and AADSTS50020?
Section titled “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
Section titled “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?
Section titled “How do I change signInAudience in the Entra admin center?”Change the account type in the Microsoft Entra admin center 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:
- Sign in to the Entra admin center and open Identity > Applications > App registrations, then select your app.
- Open the Authentication pane and find the Supported account types section.
- Select Accounts in any organizational directory to set
signInAudiencetoAzureADMultipleOrgs, then Save. - 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 for the full registration walkthrough.
Which authority URL fixes AADSTS700016 and AADSTS50194?
Section titled “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?
Section titled “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 lets an admin consent once to cover 100% of users in that tenant instead of per user.
Why does multi-tenant require publisher verification?
Section titled “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.
How do Nylas connectors fit into the fix?
Section titled “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 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
Section titled “What’s next”- Fix the need admin approval error for
AADSTS65001and tenant consent policy - Troubleshoot OAuth errors for
redirect_urimismatch (AADSTS50011),access_denied, and expired grants - Microsoft publisher verification guide to earn the blue consent badge for a multi-tenant app
- Creating an Azure auth app to register the app and set its account type