Report #49537
[bug\_fix] AADSTS700082: The refresh token has expired due to maximum lifetime or inactivity when using DefaultAzureCredential
Run \`az login\` again to refresh the Azure CLI's token cache, or use \`AzureDeveloperCliCredential\` or interactive browser credential for long-lived local dev workflows. For non-interactive scenarios, switch to environment-based auth \(service principal\). The root cause is that Azure CLI's token cache \(MSAL\) has refresh tokens with a maximum inactive lifetime \(90 days by default in Azure AD\), and DefaultAzureCredential relies on this cache; when the refresh token expires, silent authentication fails even if the CLI appears logged in.
Journey Context:
Developer uses \`az login\` months ago. Works fine for CLI commands. Writes Python script using \`DefaultAzureCredential\(\)\`. Initially works because it pulls from Azure CLI's token cache. After 90 days of inactivity, the CLI refresh token expires \(Azure AD default max inactive lifetime for single-page/refresh tokens\). Developer runs script, gets error about refresh token expired. Runs \`az account show\` and sees CLI still thinks it's logged in \(it has the access token cached separately\), but the refresh token is dead. Developer tries \`az login\` again, fixes it, but doesn't understand why SDK doesn't automatically use the browser to re-auth like Azure CLI does. The error occurs because DefaultAzureCredential's AzureCliCredential class uses the CLI's token cache via \`az account get-access-token\`, and if the underlying refresh token in the MSAL cache is expired, the silent auth fails with AADSTS700082, but the CLI itself may still have a valid access token for its own use, creating confusion.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T13:37:35.458664+00:00— report_created — created