AADSTS50194 fix: single-tenant app used the /common endpoint

What does AADSTS50194 mean?

Microsoft’s description:

Application ‘{appId}’({appName}) isn’t configured as a multitenant application. Usage of the /common endpoint isn’t supported for such applications created after ‘{time}’. Use a tenant-specific endpoint or configure the application to be multitenant.

The reference table gives this code no PascalCase name.

Every sign-in URL has a tenant part: https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize. Microsoft’s protocol overview lists the allowed values: common for work, school and personal Microsoft accounts, organizations for work or school accounts only, consumers for personal accounts only, and “tenant identifiers such as the tenant ID or domain name”.

/common tells Entra “I don’t know the user’s tenant yet”. That only makes sense for an app that accepts users from any tenant. App registrations are single-tenant by default: Microsoft’s conversion guide says “web app/API registrations in Microsoft Entra ID are single-tenant upon creation”. When such an app sends its users to /common, Entra returns 50194.

The {time} placeholder is filled in the real message. Users on the UiPath forum report the text “created after ‘10/15/2018’”. By the message’s own wording, single-tenant apps created before that date are not covered. Our reading: that is why an integration that worked for years can fail once someone sets it up again with a new app registration.

Who hits it, from user reports: SaaS connectors and automation tools that default to /common, such as WP Mail SMTP’s Outlook mailer and the UiPath Microsoft 365 activities, and custom apps that copied a /common sample.

Related codes with their own page:

• 90133: a device code request on /common or /consumers. Same family of problem, a specific flow.
• 700016: the app isn’t found in the tenant at all. That is what you get when you point the app at the wrong tenant ID.
• 90002: the tenant name or ID in the URL doesn’t exist.

Is it an attack?

No. The app is set up wrong, and the error is Entra enforcing the app’s own setting. A request to /common for a single-tenant app gets no token.

Pattern	Likely meaning
Every user of one app, starting the day it went live	The app or connector uses /common by default and the app registration is single-tenant. Fix the authority.
Started after someone created a new app registration for an existing integration	The new registration falls under the cut-off date in the message, the old one didn’t. Likely, but unconfirmed.
A few users of a multitenant SaaS app	Not this code’s pattern. Look at 50020 or 16000 instead.

How do I find it in my logs (KQL)?

Microsoft doesn’t document whether 50194 is written to the sign-in logs, or in which tenant: the request names no tenant, so it is not obvious whose log would get the row. Check your workspace first:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "50194"
| summarize Rows = count() by SourceTable

If rows exist, find the apps that send /common requests. The app ID is in the error text as well as in AppId:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "50194"
| summarize Rows = count(), Users = dcount(UserPrincipalName), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by AppId, AppDisplayName, ResourceTenantId
| sort by Rows desc

If the union returns nothing, take the app ID from the error message the user saw. ResultType is a string column, so compare it with "50194", not 50194.

How do I fix AADSTS50194?

For the user: nothing on your side. Send the full error message to whoever runs the app; it names the app ID.

For developers:

1. Keep the app single-tenant and use a tenant-specific authority: https://login.microsoftonline.com/<tenant-id>/ instead of .../common/. The error message offers this first. Microsoft’s registration quickstart says “We recommend Single tenant only - for most applications.”
2. Microsoft’s protocol overview accepts either “the tenant ID or domain name” there.
3. In third-party tools, look for a “Tenant”, “Tenant ID” or “Directory ID” field. A UiPath forum post suggests setting the Tenant parameter of the Microsoft 365 activities; nobody in that thread confirmed it worked.

For admins:

1. Only make the app multitenant if people from other organizations really need it. Microsoft’s steps: open the app registration, Authentication, Supported account types, and choose Accounts in any organizational directory. In the manifest that is signInAudience = AzureADMultipleOrgs instead of AzureADMyOrg.
2. Know what that switch does. Microsoft describes multitenant as “when you want users in any Microsoft Entra tenant to be able to use your application”. Some vendor guides, such as WP Mail SMTP’s, tell you to switch to multitenant plus personal accounts. Our view: for an internal mail or automation app, the tenant-ID fix gives the same result without opening the app to other tenants.
3. If the switch fails, check the Application ID URI. Microsoft says that for multitenant apps it must be globally unique, and “if the App ID URI doesn’t follow this pattern, setting an application as multitenant fails.”