AADSTS50059: No tenant-identifying information in the request (fix)

What does AADSTS50059 mean?

Microsoft’s description:

MissingTenantRealmAndNoUserInformationProvided: Tenant-identifying information wasn’t found in either the request or implied by any provided credentials. The user can contact the tenant admin to help resolve the issue.

Every request to the Microsoft identity platform has to resolve to one tenant before anything else can happen. The tenant comes from one of two places: the authority URL, or the credentials in the request. Microsoft’s OpenID Connect reference lists what the URL can carry:

Value	Microsoft’s description
common	Users with both a personal Microsoft account and a work or school account from Microsoft Entra ID can sign in to the application.
organizations	Only users with work or school accounts from Microsoft Entra ID can sign in to the application.
consumers	Only users with a personal Microsoft account can sign in to the application.
Directory (tenant) ID or contoso.onmicrosoft.com	Only users from a specific Microsoft Entra tenant … can sign in to the application.

common and organizations deliberately name no tenant. In an interactive browser sign-in that is fine, because the user types an address and Entra discovers the tenant from it. 50059 is what you get when there is no such step and nothing else in the request implies a tenant either: no username, no credential that belongs to a directory, no tenant in the URL.

Three codes describe tenant problems and are easy to confuse:

• 90002 means a tenant was named and doesn’t exist.
• 900023 means the tenant part of the URL isn’t a valid tenant ID or domain at all, for example undefined.
• 50059 means nothing was named, and nothing could be inferred.

Microsoft’s reference also lists AADSTS50194 for an overlapping situation: “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.” That error names the app and the endpoint. 50059 is the earlier failure: Entra hadn’t resolved a tenant, so it could not get as far as checking the app’s supported account types. Our reading, from the lab result below: which of the two you get depends on how far the request gets before the tenant is needed.

Reproduced in the lab

On 30 October 2026 an automated lab run started a device code flow for a single-tenant app registration against /common, and separately against /organizations. Both returned the same code and message:

AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.

Both rounds of the run reproduced it, four results in total. The run expected 90133, 700016 or 50194, so the documented multitenant error is not what a device code request gives you here.

The device code request carries only the client ID and the scope, which is exactly the shape 50059 describes: a request with no user and no tenant. Microsoft’s device code flow page does allow the endpoint: “tenant | Required | Can be /common, /consumers, or /organizations. It can also be the directory tenant that you want to request permission from in GUID or friendly name format.” Our reading: /common is accepted by the protocol and still fails for a single-tenant app, because the tenant can’t be inferred from anything in that first call.

No sign-in log row was captured. See how pages are checked.

Is it an attack?

No. It is an app or script pointed at a tenant-agnostic endpoint that it can’t use.

Pattern	Likely meaning
A CLI or device-code tool fails at the first step	The authority is /common or /organizations and the app registration is single-tenant.
A library default was never changed	Many SDKs default to common. For a single-tenant app it has to be set to the tenant.
Sample code copied from a multitenant tutorial	The sample’s authority was right for its app registration, not for yours.
A service-to-service call with no user	There is no user to infer a tenant from, so the URL must name the tenant.

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

Microsoft doesn’t document which sign-in table 50059 lands in. Our reading, as with 90002: the request did not resolve to a tenant, so your tenant most likely records nothing, and the error is visible to the caller rather than to you. Check anyway; this query is expected to return nothing or very little:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType in ("50059", "50194") or ResultSignature in ("50059", "50194")
| summarize Rows = count(), Apps = make_set(AppId, 10), LastSeen = max(TimeGenerated) by SourceTable, ResultType

The query includes 50194 because that is the documented error for the same mistake once the app has been resolved, and because a row of either kind points at the same fix.

What your logs can tell you is which tenant the failing app should be using. Find where it signs in successfully:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "0"
| where AppId == "<app id of the failing app>"
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppDisplayName, ResourceTenantId

ResourceTenantId carries the tenant of the resource in the sign-in. If this returns your tenant ID and the app’s configuration says common, you have found the change to make.

How do I fix AADSTS50059?

For the user: nothing to fix on your device. Microsoft’s own advice for this code is to contact the tenant admin. Pass on the name of the tool or app that failed.

For developers:

1. Put the tenant in the authority URL: https://login.microsoftonline.com/<tenant id>/..., or your verified domain instead of the GUID.
2. In the device code flow, use the same tenant value in both calls. Microsoft on the token request: “tenant | Required | The same tenant or tenant alias used in the initial request.”
3. Only use common or organizations when the app registration really is multitenant and the flow has an interactive step where the user’s address identifies the tenant.
4. Check the library default. An SDK that defaults to common needs the tenant set explicitly for a single-tenant app.

For admins:

1. Give the app’s owner your tenant ID, from Entra ID > Overview > Properties, or:

Connect-AzAccount
Get-AzTenant

2. If the app genuinely has to serve several tenants, change Supported account types on the registration to a multitenant value rather than leaving the endpoint as common against a single-tenant app. Microsoft’s signInAudience page maps the portal choices to the manifest values: single tenant is AzureADMyOrg, multitenant is AzureADMultipleOrgs.
3. For a third-party product, send the vendor the tenant ID and tell them the integration must use a tenant-specific authority.