Failed to get User Auth access token - Notebook, Lookup and Get Metadata Activities Failing

[BriefStop]

I delivered a set of pipelines to the client two months ago but they are reporting that the pipelines are failing. When I open up the pipeline and check the failed run, it fails when running activities for Notebook, Lookup and Get Metadata.

All of these activities have failure messages starting with "Failed to get User Auth access token. The error message is: Failed to get User Auth access token. The error message is: AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '2025-02-12T20:24:50.5122150Z' and the TokensValidFrom date (before which tokens are not valid) for this user is '2025-03-31T16:00:07.0000000Z'."

I was able to fix these failures by opening up each activity and reconfiguring every activity with the same exact settings before saving and running. The pipeline is working now but I'm not sure how we can prevent this in the future as my work with the client is supposed to be finished. 

I'm thinking what is happening is that the account I used to develop the pipelines ran into a password expiry a month after I left the project and that logging back in and reconfiguring set up a fresh token. Is this correct? As well, how do I keep the token refreshed after I leave the project?

• Does the client need to perform a takeover of my developed items with a regularly used account?
• What happens if the regularly used account runs into password expiry and the token needs to be refreshed again?
• How long does an account have before the token needs to be refreshed? 45 days?
• What are the best practices for setting up a regularly used Fabric account for this? Should the Service Principal account be used?

[v-saisrao-msft]

Hi @BriefStop,

Thank you for reaching out to the Microsoft Fabric Forum Community.

Thanks for the detailed context this is a common issue in pipeline implementations where user-based authentication is used. You're right in your diagnosis: the failures you're seeing are caused by token revocation tied to a user account, and reconfiguring the activities re-established a fresh token using your credentials. 

Occurs when an OAuth2 token issued to a user account is no longer valid. In your case, it likely happened due to a password reset or change, after your development work was completed. Since your user token was tied to the activities in the pipeline, those activities failed when the token was revoked. 

Please refer the below links for your reference: 
Error code AADSTS50173 - The Provided Grant Has Expired Due to it Being Revoked | Microsoft Learn 
Microsoft Entra authentication & authorization error codes - Microsoft identity platform | Microsoft... 

Refresh tokens in the Microsoft identity platform - Microsoft identity platform | Microsoft Learn 

• To prevent this issue from happening again after the handover, please avoid using personal or developer accounts in pipeline configurations. User-based tokens are linked to credentials and are revoked when passwords are changed or MFA settings are updated, causing failures in activities such as Notebooks, Lookups, and Get Metadata. 
• The suggested method for handling production workloads in Microsoft Fabric is to use a Service Principal with the client credentials grant flow. You should register an app in Microsoft Entra ID, assign it the necessary roles (such as Fabric Contributor), and configure your linked services and notebooks to authenticate using it. Ensure that credentials are securely stored in Azure Key Vault. This approach removes the need for interactive logins, allows tokens to be managed programmatically, and eliminates reliance on individual user accounts. 
• The client should reconfigure all pipeline authentication using a Service Principal or a Managed Identity (if supported). This change will ensure that the pipelines no longer depend on your personal credentials or expired session tokens, providing long-term stability and control. 

If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly.

Thank you.

[BriefStop]

Thank you very much! I'm looking up the documentation for your next steps and I'm not sure where to start:

• I'm checking the documentation to "register an app in Microsoft Entra ID, assign it the necessary roles" and I'm checking https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app?tabs=certificate%2... but I don't see anything specific for Fabric? How would I configure this for a Fabric workspace
• What happens if the client doesn't have an Azure Key Vault?
• When you refer to "The client should reconfigure all pipeline authentication using a Service Principal or a Managed Identity (if supported)." does this mean the Fabric account with the Service Principal/Managed Identity needs to perform a takeover on the developed items?

[v-saisrao-msft · Accepted solution]

Hi @BriefStop,

You're right most documentation around app registration is general to Microsoft Entra ID.

• Register an App in Entra ID 
  Choose the "Client credentials" flow (either certificate or client secret). 
  Save the Application (client) ID, Directory (tenant) ID, and the client secret or certificate details. 
• Grant the App Access to the Fabric Workspace 
  In the Fabric workspace, go to Settings > Permissions. 
  Add the Service Principal (App ID) as a Contributor or higher role depending on access needs. 
• Configure the Linked Services 
  In your Data Pipeline or Notebook Linked Service, choose Service Principal authentication. 
  Provide the tenant ID, client ID, and client secret. 

• Use Azure Key Vault 
  Store the client secret securely in Azure Key Vault. 
  Reference the secret from the Linked Service to avoid hardcoding sensitive data. 

• If Azure Key Vault is unavailable, you can enter secrets directly into the Linked Service configuration. Although this method works, it is less secure and not recommended for production environments. For improved security and maintainability, it is advisable to use Azure Key Vault whenever possible.
• The Service Principal doesn’t "own" the pipelines in the traditional sense, but once it's configured for authentication, all activities (e.g., Notebooks, Lookups, Get Metadata) will run using its credentials. This effectively decouples the pipelines from user-based tokens, ensuring long-term stability even if user accounts are removed or passwords are changed. 

If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly.

Thank you.