Report #92622
[bug\_fix] Azure SDK or CLI fails with 'AADSTS700082: The refresh token has expired due to inactivity' in long-running automation
For automated/non-interactive scenarios, migrate from 'az login' with user credentials or service principal with client secret \(which have 24-hour refresh token lifetimes for SPs in some configurations\) to Service Principal authentication using a Certificate \(X509\) or switch to Managed Identity if running in Azure. Alternatively, use the Azure Identity SDK's DefaultAzureCredential with AZURE\_CLIENT\_ID, AZURE\_CLIENT\_SECRET environment variables, which handles token refresh automatically without relying on the CLI's token cache. The root cause is that 'az login' persists refresh tokens in ~/.azure/msal\_token\_cache.json which expire after 24 hours \(SPs\) or 90 days \(users\) of inactivity.
Journey Context:
Developer writes a Python script that runs for 48 hours using Azure Storage SDK with DefaultAzureCredential. It authenticates initially using AZURE\_CLIENT\_ID/SECRET/TENANT\_ID. After 24 hours, it fails with AADSTS700082. The developer checks the App Registration in Azure Portal and sees the client secret is still valid \(not expired\). They check if the SP was disabled \(it wasn't\). They examine the error code and realize it's the refresh token, not the client secret. They were using 'az login --service-principal' earlier in the script which cached a refresh token. Switching to purely environment-variable based authentication with DefaultAzureCredential \(which uses ClientSecretCredential directly and manages token caching in-memory\) avoids the stale CLI token cache issue.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T14:03:26.410743+00:00— report_created — created