Why Do OAuth-Based Data sources Expire on Power BI Gateway and What You Can Do About It

You have built a beautiful Power BI report, published it, and configured your on-premises data gateway. Everything works perfectly until a few days or weeks later, you see this annoying message:

"Your data source credentials have expired. Please reauthenticate."

Frustrating? Absolutely. Preventable? Mostly, yes.

Let us break down what is really happening behind the scenes and how you can design your Power BI environment to avoid this common OAuth expiry problem.

The OAuth Expiry Problem in Power BI Gateway

OAuth is great for secure, token-based cloud authentication. But there is a catch - tokens expire:

• Access tokens are valid for around 60 to 90 minutes.

• Refresh tokens last a few days to weeks but depend heavily on tenant policies.

When Power BI Service connects through an on-premises Gateway, token behavior differs from standard cloud connectors. This causes many to face sudden credential expiry errors.

Token Storage and Expiry Nuances

Power BI stores tokens securely, but cloud services like Azure AD or Salesforce may invalidate tokens if:

• They are not used frequently.

• New consent is required by organisational policy.

• The user changes their password or becomes inactive.

Enterprise Tenant Policies and Consent Rules

OAuth expiration is not a bug - it is a security feature. Enterprises often enforce token expiry every 14, 30, or 90 days depending on their security needs.

OAuth Is Always User-Bound

Most OAuth implementations in Power BI tie tokens to individual user accounts. So, if that user:

• Is disabled,

• Goes on leave, or

• Changes their password,

the token stops working, triggering the dreaded "Please reauthenticate" message.

OAuth Behavior in Power BI Desktop & What Developers Often Miss

Many Power BI developers work mainly in Power BI Desktop and are confused when:

• They authenticate once in Desktop,

• The report works fine locally,

• But after publishing, it suddenly asks for credentials again.

Here is why:

• OAuth tokens in Desktop live only for the current session or limited time.

• When the token expires, Desktop will prompt again for login.

• Power BI Service and Gateway manage tokens differently, so token expiry in Service can break refreshes even if Desktop works fine.

Why Do Developers Complain About OAuth in Power BI?

Common complaints are:

• "Why does my published report break when my Desktop version works?"

• "Why do I keep getting asked to login again and again?"

• "Why does the Gateway ask for credentials even though I logged in before?"

The answer is token expiry and user-bound OAuth tokens combined with differences in token management between Desktop, Service, and Gateway.

Best Practices for Power BI Developers to Avoid OAuth Frustrations

1. Use Service Principals for supported sources
   Authenticate using Service Principals instead of personal user accounts whenever possible. This avoids token expiry due to user changes.

2. Clear cached credentials in Desktop when facing errors
   Go to File > Options > Data Source Settings and clear cached OAuth tokens to force a fresh login.

3. Test dataset refresh in Power BI Service before publishing widely
   Catch OAuth or consent issues early by validating refresh success in Service.

4. Use dedicated service users for OAuth connections without SPNs
   Create dedicated user accounts with minimal permissions and no MFA. Avoid using personal accounts to reduce risk.

5. Educate your team on OAuth expiry and security policies
   Understand that token expiry is by design, not a bug. Prepare for reauthentication cycles as part of security hygiene.

Starburst Connector - Same Story, New Names

The Starburst Enterprise connector is now renamed simply as the Starburst connector, with a new Starburst secured by Entra ID connector also available.

Even Starburst faces OAuth expiry issues. It offers two connection modes in Power BI:

• OAuth-based connector (recommended)

• Username/Password basic authentication

If you use the OAuth connector via Gateway, you will see expiry problems such as:

"Your OAuth2 credentials are invalid."

This happens if:

• The user configured is inactive,

• Tokens were not refreshed, or

• Tenant policies require new consent.

This is not a Starburst-specific bug. It is just how OAuth behaves inside Power BI Gateway.

What Can You Actually Do?

Here are practical solutions to manage OAuth expiry:

1. Use Service Principals where possible
   For Azure-based sources like SharePoint and Azure SQL, configure App Registrations with Client Secrets or Certificates. Service Principals do not expire like user tokens, are not tied to individuals, and offer more stable refreshes.

2. Use dedicated service accounts for OAuth sources without SPNs
   For platforms like Salesforce or Starburst where SPNs are not supported, create dedicated user accounts, turn off MFA for these accounts, and give minimal required permissions only.

3. Avoid Gateway for cloud-to-cloud OAuth sources when possible
   Skip Gateway and connect directly via cloud connectors such as SharePoint Online, Dynamics 365, and Starburst Cloud. This avoids Gateway token expiry problems.

4. Monitor token expiry proactively
   Set alerts or dashboards to track credential expiry using PowerShell, Admin APIs, or Power BI reports.

5. Use long-lived tokens where possible
   Some platforms like Snowflake and GitHub provide personal access tokens or API keys that last longer. Explore these if your organisation policy allows.

Why OAuth2 Token Expiry Breaks Power BI Gateway Refreshes and Why Microsoft Says You Should Move Away from Dataflow Gen1

If you’ve run into InvalidConnectionCredentials or AccessUnauthorized errors in Power BI when using OAuth2 authentication through a gateway, you’re not alone. This issue is so widespread that Microsoft has officially documented it and, in some cases, completely discontinued mid-stream token renewal.

The Core Problem : Mid-Stream OAuth2 Token Refresh

When connecting to cloud sources using OAuth2 (for example, SharePoint Online, Snowflake SSO, Starburst/Trino), Power BI obtains an access token and sometimes a refresh token.

• Access tokens typically expire 1 hour after the refresh starts (sometimes earlier due to data source or tenant policies).

• For long-running refreshes, the system needs to refresh the token mid-process.

• Gateways (both On-premises Data Gateway and VNet Gateway) do not support this mid-stream renewal meaning once the token expires, the refresh fails.

Microsoft confirms this in their documentation:

“When you use OAuth2 credentials, the gateway currently doesn't support refreshing tokens automatically when access tokens expire (one hour after the refresh started). This limitation for long running refreshes exists for both VNet gateways and on-premises data gateways.”
— Power BI Docs: Refresh Scenarios & Limitations

Gen1 Dataflows: Microsoft Disables Mid-Stream Refresh Completely

This limitation is not restricted to datasets Gen1 Dataflows are now explicitly affected because Microsoft has removed mid-stream token refresh altogether.

From Microsoft’s own response to a support case (Mindtree, 2024):

Why do I get the errors "InvalidConnectionCredentials" or "AccessUnauthorized" in Gen1 Dataflows?
“When you use OAuth2 credentials in Dataflow Gen1, the gateway doesn't support refreshing tokens automatically when access tokens expire. Tokens typically expire 1 hour after the refresh starts… midstream token refresh is completely discontinued from Dataflow Gen1 and the product team will no longer support it. This is a product limitation when using Dataflows Gen1.”

Additionally:

• Gen1 Dataflows will be deprecated (no ETA yet).

• Microsoft’s official guidance:

“Dataflow Gen2, Semantic models, and data pipelines are able to refresh tokens mid-stream and should not be impacted.”

• Translation: If you want mid-stream token refresh, you must move to Gen2 but Gen2 comes with different cost metrics.

Why This Hits Datasets and Gen1 Dataflows Hard

Datasets via Gateway

• Entire refresh path runs through the gateway.

• Long-running queries (e.g., big joins, complex mashups) exceed the 1-hour token window.

• No mid-stream renewal = token expiry error.

Gen1 Dataflows

• Previously could handle some mid-stream renewals in service.

• Microsoft has now discontinued that support entirely.

• Even short-to-medium refreshes can fail if token expires mid-run.

Gen2 Dataflows :The “Fix” With Trade-Offs

Microsoft’s official solution is to move to Gen2 Dataflows or use Semantic Models/Data Pipelines for OAuth2-based sources.
Benefits:

• Mid-stream token refresh is supported.

• Refresh failures due to OAuth2 expiry are far less likely.

Drawbacks:

• Gen2 dataflows charge for:

  1. Time elapsed during processing.

  2. Self-hosted gateway usage.

  3. CU (capacity unit) consumption in more scenarios than Gen1.

• In community feedback, some organizations report substantially higher capacity consumption compared to Gen1.

Workarounds (If You Can’t Migrate Yet)

1. Shorten Refresh Duration

   • Optimize M queries with folding and pushdown.

   • Filter early, prune columns, avoid row-by-row transformations.

2. Split Models

   • Break large datasets into smaller ones and use composite models.

3. Use Non-OAuth2 Authentication

   • For some connectors, switch to service principal, key, or basic auth.

4. Schedule Strategically

   • Avoid stacking multiple long-running refreshes on the same gateway.

The Bigger Picture

This isn’t a bug , Microsoft now treats it as by design for Gen1 Dataflows and current gateways.

• For datasets via gateway: Limitation still exists.

• For Gen1 Dataflows: Limitation is now permanent and support is withdrawn.

• For Gen2 Dataflows: Fixed, but costs more.

In plain terms:
If you need reliable mid-stream OAuth2 token refresh, the only Microsoft-supported path forward is Gen2 Dataflows or a direct service refresh without gateway involvement.

Final Thoughts

OAuth token expiry is here to stay because it is part of strong security practices. But you can:

• Architect your environment to reduce disruptions.

• Use Service Principals for reliable access.

• Prefer cloud-native connectors to avoid Gateway pitfalls.

• Manage Starburst and other connectors smartly with dedicated accounts.