# AADSTS50059: No tenant-identifying information in the request (fix) Canonical: https://brambrinkmeier.com/entra/aadsts/50059/ By Bram Brinkmeier. JSON: https://brambrinkmeier.com/api/aadsts/50059.json **Short answer:** AADSTS50059 means the request named no tenant and carried nothing Entra could use to work one out. It happens when a single-tenant app calls /common or /organizations without a user hint, for example in the device code flow. It is a configuration error with low attack value. Put your tenant ID or domain in the authority URL. **Fix:** Developer: replace `common` or `organizations` in the authority URL with your tenant ID or verified domain, and use the same tenant value on both the device code request and the token request. If the app really must serve several tenants, change Supported account types to multitenant instead. | Field | Value | |---|---| | Code | AADSTS50059 | | Microsoft name | MissingTenantRealmAndNoUserInformationProvided | | Category | App configuration | | Type | Configuration error | | Attack signal | Low: usually configuration or user error | | In Microsoft's error reference | Yes | | Verification | lab-reproduced (2026-10-30) | | Last updated | 2026-10-30 | ## 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](https://brambrinkmeier.com/entra/aadsts/90002/) means a tenant *was* named and doesn't exist. - [900023](https://brambrinkmeier.com/entra/aadsts/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](https://brambrinkmeier.com/entra/aadsts/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](https://brambrinkmeier.com/methodology/). ## 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](https://brambrinkmeier.com/entra/aadsts/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: ```kusto 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: ```kusto union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs | where TimeGenerated > ago(30d) | where ResultType == "0" | where AppId == "" | 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//...`, 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: ```powershell 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. ## Evidence Reproduced in a lab tenant on 2026-10-30 (Device code request against a lab tenant; scenario: Device code on /common by a single-tenant app). First line returned: > AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. Lab-run rows naming this code (14; full list at https://brambrinkmeier.com/lab-runs.json): | Date | Scenario | Expected | Got | Message (first line) | |---|---|---|---|---| | 2026-10-30 | Device code on /common by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /organizations by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /common by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /organizations by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /common by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /organizations by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /common by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /organizations by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /common by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-30 | Device code on /organizations by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-31 | Device code on /common by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-31 | Device code on /organizations by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-31 | Device code on /common by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | | 2026-10-31 | Device code on /organizations by a single-tenant app | 90133 / 700016 / 50194 | 50059 | AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials. | ## Sources 1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes) 2. [Microsoft identity platform and the OAuth 2.0 device authorization grant flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code) 3. [OpenID Connect on the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc) 4. [Validation differences by supported account types (signInAudience)](https://learn.microsoft.com/en-us/entra/identity-platform/supported-accounts-validation) 5. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs) ## Related codes [AADSTS90002](https://brambrinkmeier.com/entra/aadsts/90002/), [AADSTS900023](https://brambrinkmeier.com/entra/aadsts/900023/), [AADSTS50020](https://brambrinkmeier.com/entra/aadsts/50020/), [AADSTS700016](https://brambrinkmeier.com/entra/aadsts/700016/), [AADSTS70016](https://brambrinkmeier.com/entra/aadsts/70016/) ## License and citation CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change. Cite as: Bram Brinkmeier, "AADSTS50059: No tenant-identifying information in the request (fix)", https://brambrinkmeier.com/entra/aadsts/50059/ (CC BY 4.0), last updated 2026-10-30.