Low severityauthentication
Power BI Error:
AADSTS90019, Authority Missing Tenant Identifier: Causes & Fix
What does this error mean?
Microsoft Entra ID (Azure AD) can't resolve which tenant to authenticate against from the incoming request.
Common causes
- 1Authority URL set to `https://login.microsoftonline.com/common` (or `/organizations`) while the flow requires a concrete tenant — most common in custom-coded Power BI Embedded and ADF integrations
- 2Client credentials / service principal flow (daemon app, ADF SPN, Databricks SPN, Fabric capacity auth) calling `/common` — app-only tokens are never valid against `/common` or `/organizations`
- 3User signs in with a personal Microsoft account (MSA) on an endpoint configured for work/school accounts only, so Entra ID has no tenant to bind the request to
- 4User's UPN/email domain is not added or not verified in any Entra ID tenant (typo in domain, unverified custom domain, or guest invite never redeemed)
- 5On-behalf-of or token-exchange flow where the upstream token's `tid` claim is missing or stripped by an API gateway / reverse proxy before it reaches Entra ID
How to fix it
- 1Replace `/common` or `/organizations` in your authority URL with the explicit tenant GUID or verified domain — e.g. `https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize`. This resolves the majority of AADSTS90019 cases
- 2For Power BI Embedded, ADF linked services, Fabric capacity auth, or Databricks Unity Catalog connections: open the connection/linked-service config and set the Tenant ID field explicitly instead of leaving it blank
- 3For any client credentials / service principal flow: hardcode `/{tenant-id}` in the authority — `/common` and `/organizations` are unsupported for app-only tokens and will always fail with AADSTS90019
- 4In MSAL apps, set the authority via `WithTenantId()` (or `TenantId` in app config) rather than relying on `AzureCloudInstance.AzurePublic` defaults; in ADAL/legacy code, replace the authority string directly
- 5Verify the signing-in user's domain in the target tenant: Entra admin center → Custom domain names. If `user@contoso.com` is failing, `contoso.com` must be added and verified in that tenant, or the user must be invited as a guest
Beyond the docs
Common practitioner solutions not covered in the official documentation.
- 1Code fix: Replace the generic authority with a tenant-specific one — change 'https://login.microsoftonline.com/common' or '/organizations' to 'https://login.microsoftonline.com/<your-tenant-id>' in your auth config or ADF linked service
- 2PowerShell: Find your tenant ID — (Get-MgContext).TenantId — or in Entra ID → Overview → Tenant ID
- 3Azure CLI: az account show --query tenantId -o tsv
- 4MSAL config (Python/JS/C#): For daemon apps using client credentials flow, set authority to 'https://login.microsoftonline.com/<tenant-id>' — /common and /organizations are never valid for application-level token acquisition
- 5ADF linked service: Open the linked service in ADF Studio → Authentication method: Service Principal → verify the Tenant field contains your actual Tenant ID (a UUID), not the string 'common' or 'organizations'
Example log output
# MSAL / service principal (client credentials flow):
AADSTS90019: No tenant-identifying information found in either the request or implied by any provided credentials.
Please use a tenant-specific endpoint or pass a tenant id to identify the tenant.
# ADF linked service test connection failure:
{
"code": "InvalidTemplate",
"message": "AADSTS90019: No tenant-identifying information found."
}