Power BI Authentication Errors: A Reference Index of AADSTS Codes

AADSTS stands for Azure AD Security Token Service. It is the part of Microsoft Entra ID (formerly Azure Active Directory) that issues, validates and rejects the tokens every Microsoft 365 service uses to confirm who you are.

Power BI does not run its own login. When a user signs in to Power BI Service, when a scheduled refresh kicks off, or when a service principal connects to a Fabric workspace, the request is handed off to the Security Token Service. If the STS rejects the request, you see an AADSTS code in the URL, the browser, or the Power BI Service refresh history.

The number is the only thing that reliably tells you what went wrong. The English message attached to it is often generic ("Sign-in failed") and the same message can hide very different root causes. Microsoft documents every code in the Entra ID authentication and authorization error codes reference, but with more than 300 codes that page is not a fast diagnostic tool. This index narrows it down to the codes that actually surface in Power BI environments.

An AADSTS error in a user-facing browser flow is annoying. The same error inside an unattended pipeline is invisible until someone notices that yesterday's data never arrived.

Three pipeline scenarios produce most of the AADSTS noise that data teams see:

Scheduled refresh failures. A Power BI dataset refresh runs under stored credentials or a service principal. When the credential expires, the user is disabled, or Conditional Access starts blocking the sign-in, the refresh fails. The Power BI Service refresh history shows the AADSTS code in the error message. The dashboard keeps serving the previously cached data, which is the worst possible outcome: nothing looks broken, but the numbers are stale.

Gateway disconnects. The on-premises data gateway authenticates to Power BI Service using OAuth tokens. When the gateway service account hits AADSTS errors, the gateway shows offline in the admin portal. Every dataset routed through that gateway starts failing in the next refresh window.

Service principal expirations. Service principals authenticated with a client secret have an expiry date. When that secret expires, every refresh, REST API call, and tenant-level operation that uses that principal returns an AADSTS error in the same hour. This is the failure mode behind most "why did all our refreshes break at the same time" incidents.

Across all three: the AADSTS code is your signal that the problem is upstream of the dataset, not in the data itself. Treating an AADSTS error as a data problem wastes time.

AADSTS errors group naturally into a handful of failure modes. Use this index to identify which class of problem you are looking at, then click through to the dedicated fix page for the specific code.

#### Endpoint, request and protocol errors

These errors fire when the request itself is malformed before any user check happens. They usually point at a misconfigured client app, a wrong reply URL, or a request hitting the wrong endpoint.

#### Login and credential errors

This is the largest category. The user reached Entra ID, but something about the account, password, device, or assignment blocked the login. Most help-desk tickets land here.

#### Token, session and redirect errors

These errors happen mid-flow. A token is missing, expired, scoped to the wrong tenant, or the redirect URI does not match what is registered. Common after tenant migrations or app re-registrations.

#### Service and infrastructure errors

Errors that originate in Entra ID or Power BI service infrastructure rather than the user. Often correlated with service incidents, federation problems, or SAML configuration drift.

#### Multi-factor and policy errors

Conditional Access, MFA enforcement, and tenant outbound policies block what would otherwise be a valid login. The user's credentials are correct; the policy stops the session from completing.

#### Application and client errors

The client application requested a scope, grant, or response type that the registration does not allow. These typically surface during custom app development against Power BI APIs, not for end users.

#### Conditional Access and consent

User or admin consent has not been granted for the requested permissions. The login itself works; the application is not authorised to act on the user's behalf.

#### Other

Less frequent codes that do not fit the other categories: account picker prompts, federation message validation, on-premises password validator timeouts.

MetricSign reads the Power BI activity log, refresh history, and gateway status, and parses the AADSTS code out of the failure messages. Where the Power BI Service shows a generic "refresh failed", MetricSign extracts the underlying code and surfaces it in the alert.

Concrete detection paths:

• Refresh failures with AADSTS in the error message. Caught from the dataset refresh history. The alert names the dataset, the workspace, the AADSTS code, and the linked downstream reports.
• Gateway OAuth issues. Caught from gateway logs and the gateway status endpoint. When the gateway flips offline because of an AADSTS rejection, MetricSign alerts before the next refresh window starts.
• Service principal expirations. A sudden cluster of refresh failures that all reference the same client ID is treated as a likely service principal problem. The alert groups the failures into one incident instead of paging on each dataset.
• Cross-tenant authentication. Codes such as AADSTS500021 (tenant access denied) and AADSTS90072 (user not in tenant) signal cross-tenant or guest-user issues, which need a different response than a normal credential failure.

Honest caveat: MetricSign does not see browser-side login errors. If a user gets AADSTS50105 opening Power BI Service in a browser, that error never reaches MetricSign because it is not part of any pipeline run. The scope is pipeline-impacting authentication failures, not end-user login support.

When an AADSTS code shows up, work through it in this order rather than searching for the message text:

1. Read the code, not the message. The code is precise; the message is not. AADSTS50173 and AADSTS50057 both surface as "sign-in failed" but require completely different fixes.
2. Identify the category. Login and credential, token and session, policy, service principal, infrastructure. The category determines who can fix it. The index above maps each code to its category.
3. Check whether it is one user or many. A single user with AADSTS50105 is an entitlement problem for that user. Every refresh in the tenant returning AADSTS50105 is a service principal that lost its assignment.
4. Check the timing. A burst of failures at the same minute usually means a credential expired or a Conditional Access policy was published. A slow drift over days usually means a permissions or licensing issue.
5. Look up the code in the Microsoft reference. Use the authentication and authorization error codes reference for the canonical description and the documented fix.
6. Reproduce in a controlled flow if you can. For service principal errors, use the Microsoft Graph or Power BI REST API with the same principal to confirm the failure outside the refresh path.

Skipping the category step is the most common mistake. Engineers Google the message text and end up applying a credential fix to a Conditional Access problem.

Some AADSTS codes can be solved by the dataset owner. Others require a tenant admin or a Conditional Access policy change. The split matters because escalating a fixable issue wastes time and trying to self-fix an admin-only issue creates a second incident.

You can usually fix yourself:

• AADSTS50173 (grant expired): re-enter credentials in the dataset.
• AADSTS90094 (admin consent required): request consent through the standard tenant flow; the request itself is yours to send.
• AADSTS65004 (user declined consent): re-attempt the consent flow.
• Service principal expirations where you own the app registration: rotate the secret or move to a certificate.

Tenant admin required:

• AADSTS53003 (BlockedByConditionalAccess): admin must adjust the Conditional Access policy or grant an exception.
• AADSTS500021 (tenant access denied): admin must enable cross-tenant access or remove a B2B restriction.
• AADSTS50105 for a service principal: admin must grant the right workspace or capacity assignment.
• AADSTS700016 (UnauthorizedClient): admin must approve the app registration in the tenant.
• Anything in the Service and infrastructure category: federation, SAML and on-premises validator issues are not user-fixable.

If you do not have access to the Entra admin centre, anything that requires changing a policy, an app registration, or a tenant-level setting belongs with the admin. Escalate with the AADSTS code, the affected dataset or report, and the timestamp range. That is enough for the admin to act without a back-and-forth.

Every code linked from this hub has its own page with the canonical Microsoft description, the typical Power BI scenario it appears in, and the fix steps. Use this list to jump directly to the code you are looking at.

The full reference covers more than 300 AADSTS codes. The codes above are the ones that actually surface in Power BI pipelines often enough to have measurable search volume; the rest are documented in the Microsoft reference linked in the first section.

Authentication failures should not surface first as a broken dashboard. MetricSign monitors Power BI service principal validity, gateway OAuth status, and refresh-context auth errors, and alerts you before the report shows yesterday's data.