Dataflow Gen2 Lakehouse connection fails with AADSTS70008

Hi ShubhamJain2​,

The error you're getting suggests that the auth token expired and you need to re auth. You say you have done this already, so maybe it is stuck somehow. 

What are your sources/targets for the dataflow? 
Have you re-authenticated both the source connection and the target connection?  

What happens if you create a brand new dataflow gen 2, do you get the same error? 

If I helped, consider giving a like. If I solved your problem or answered your question, mark this post as the solution to allow others to find it easily. 
Proud to be a Fabric Super User

Hi ShubhamJain2​,

Thanks for posting the full details. The new information makes this look more specific than a normal “please sign in again” case.

Microsoft documents the Fabric Lakehouse connector for Dataflow Gen2 as supporting Organizational account authentication, so the authentication method you are using is valid.

See the Lakehouse connector documentation.

The key detail in your screenshot is that Fabric is failing while trying to update the connection credentials and returning AADSTS70008.

Normally, a fresh interactive sign-in should replace an expired refresh token. Since you have already:

• signed in interactively again;
• completed MFA;
• tested multiple browsers/InPrivate;
• recreated the connection;
• confirmed the Lakehouse itself is accessible;
• and the error still returns;

I would not keep treating this as a simple expired-browser-session issue.

At this point I would separate the problem into three layers:

Microsoft Entra sign-in
→ Fabric connection credential/token storage
→ Dataflow Gen2 binding to that connection

Your interactive Entra sign-in appears to be working, so the failure may be occurring when Fabric tries to persist or reuse the credential on the connection object.

I would also avoid changing the tenant or account structure until Microsoft confirms that is necessary. Nothing in the current Lakehouse connector documentation suggests that a Fabric trial or a normal organizational account should inherently prevent this connection from working.

The correlation ID, trace ID and timestamp you included are exactly the details Microsoft would need to inspect the server-side authentication failure.

Since your original community post was marked as spam and your Azure Basic support case did not provide a technical escalation path, I would ask Community Support / the Fabric Community team to help get this specific case in front of the Data Factory or connection/authentication team rather than repeating sign-in troubleshooting again.

One useful additional test, if you have not already done it, would be to create:

a brand-new workspace
→ a brand-new Lakehouse
→ a brand-new Dataflow Gen2
→ a brand-new Lakehouse connection

using the same organizational account.

If AADSTS70008 reproduces there as well, that would strongly suggest this is not stale state in one existing Dataflow or workspace.

If the new environment works, then the problem is more likely tied to the original connection/workspace artifact.

I would keep the existing tenant intact for now and use that clean-room test only to isolate the scope.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Update: Clean-room diagnostic test completed

Thanks again for the guidance. I have completed the first isolation test.

Environment:

• New workspace: Fabric_OAuth_Diagnostic, using the same Fabric trial capacity.
• New Lakehouse: LH_OAuth_Diagnostic.
• New Dataflow Gen2: DF_OAuth_Diagnostic.
• Same onmicrosoft.com organizational account and OAuth authentication.

Results:

1. I created a new connection to LH_OAuth_Diagnostic. The connection succeeded, and the Lakehouse navigator opened and displayed its items.
2. In the same diagnostic workspace and the same new Dataflow Gen2, I selected the original LakeHouse_Training from Nikolai_Schuler_Udemy and attempted to create a separate connection named LH_Training_Diagnostic_Connection.
3. That attempt immediately returned Invalid credentials.
4. I confirmed that [email protected] has the Admin role in the original workspace.

This suggests the problem follows the original Lakehouse or its connection/authentication path, rather than affecting every Lakehouse connection in the tenant. The latest attempt displayed the generic Invalid credentials message. I have not yet confirmed whether it generated a new AADSTS70008 event.

Could a Data Factory or Lakehouse connector specialist help investigate why the new Lakehouse connection succeeds while the original Lakehouse connection fails from the same Dataflow Gen2 and organizational account?

I can provide the latest Entra sign-in details and correlation IDs privately if needed.