Where Does az login Store Credentials

A few years ago, I helped a team clean up after a contractor laptop went missing. The contractor had signed in to Azure from a terminal every day for months, and nobody knew what that machine still held. The security lead asked a simple question: where does az login store credentials, and can someone use them? We had to find the answer fast, and the first draft of it was wrong.

Many engineers believe the Azure CLI saves their password. It does not. It saves tokens, profile data, and sometimes service principal secrets, and the protection on those files depends on your operating system and CLI version. This guide shows you exactly where those files live, what is inside them, how to check their permissions, and how to reduce the risk on laptops, build agents, and containers.

Where Does az login Store Credentials on Disk?

The Azure CLI keeps all of its local state in one folder called .azure inside your home directory. On Linux and macOS that is ~/.azure. On Windows it is %USERPROFILE%\.azure. You can move it by setting the AZURE_CONFIG_DIR environment variable.

Run these commands to see what is there:

ls -la ~/.azure

The ls -la command lists every file, including hidden ones, with owner and permission details. Look at the permission column. If other users can read these files, you have a problem.

Get-ChildItem -Path "$env:USERPROFILE\.azure" -Force

Get-ChildItem lists the folder contents in PowerShell. The -Force switch includes hidden items. Compare this with the Linux listing, because the file names differ slightly by version and platform.

The Files That Matter

Since version 2.30.0, the CLI uses the Microsoft Authentication Library (MSAL), a library that handles sign-in and token caching. Microsoft’s documentation states that the MSAL token cache and service principal entries are saved as encrypted files on Windows, and as plaintext files on Linux and macOS.

Older tools that read accessTokens.json no longer work. Behavior can differ by CLI version and by whether a keychain or Secret Service is available, so verify on your own machines instead of assuming.

Pro Tip: In my experience, the file name tells you a lot. I look for .json on Linux build agents and treat it as readable by anyone who can read that folder. I plan my controls around that assumption.

What Is Actually Inside the Token Cache?

The CLI does not store the password you type. When you sign in, Microsoft Entra ID (the identity service for Azure) returns two token types. An access token is a short-lived proof of identity, usually valid for around an hour. A refresh token lets the CLI get new access tokens without asking you to sign in again.

The refresh token is the sensitive part. Whoever copies the cache can often keep requesting new access tokens until the refresh token expires or is revoked. Older guidance describes revocation after 90 days of inactivity, but your tenant administrator controls session lifetime through policy, so check your own settings.

You can see the access token the CLI would hand to another tool:

az account get-access-token --resource https://management.azure.com/

This prints a bearer token for Azure Resource Manager, Azure’s deployment and management layer. It also prints the expiration time. Treat the output like a password. This guide on az account get-access-token explains the output fields in more detail.

What the Profile File Reveals

azureProfile.json does not contain tokens. It does contain subscription IDs, tenant IDs, and your user name. That is useful reconnaissance for an attacker. You can see the same information with az account show and az account list.

Each tenant in Azure is a separate directory, so a profile that lists several tenants tells you where a user has access.

Pro Tip: I once reviewed a “harmless” support ticket that included a pasted azureProfile.json. It exposed three subscription IDs and two tenant IDs. Now I tell teams to sanitize every log and screenshot before sharing.

How Storage Differs by Login Method

Where az login stores credentials depends partly on how you sign in. The command is the same, but the secret you hand it changes what lands on disk.

Service principals deserve extra attention. A service principal is an identity for an app or script. When you sign in with a client secret, the CLI keeps an entry for it so later commands can renew tokens. That means a secret that lasts months may sit in your .azure folder. Learn how to create a service principal in Azure with a short secret lifetime.

A managed identity avoids this problem. Azure creates and manages the identity for a resource such as a VM, and your code receives tokens without storing any secret. See what a managed identity in Azure is and use it wherever your code runs on Azure compute.

az login --identity

This signs in using the identity attached to the Azure resource running the command. No client secret, password, or certificate is written because none exists. For a user-assigned identity, add --client-id <managed-identity-client-id>.

Pro Tip: I audit service principal secrets by listing their expiration dates. Any secret older than 12 months gets replaced with a managed identity or a federated credential.

Check Whether Your Own Files Are Exposed

Don’t guess. Check your actual permissions. On Linux or macOS, the cache should be readable only by you.

stat -c '%a %U %n' ~/.azure/*

stat prints the numeric permission mode, the owner, and the file name. On macOS, use stat -f '%Lp %Su %N' ~/.azure/* instead. You want 600 for files, meaning read and write for the owner only, and 700 for the folder.

If the permissions are too open, tighten them:

chmod 700 ~/.azure
chmod 600 ~/.azure/*

chmod 700 limits the folder to your account. chmod 600 limits each file to read and write by you. This changes only local file access and does not affect Azure resources. Wildcards skip subfolders, so check those too.

Check Who Is Signed In

Confirm which identity the cache currently represents:

az account show --output table

This shows the active subscription, tenant, and signed-in user. If you see an identity you do not recognize on a shared machine, sign out and investigate. Use the az account set command when you need to switch subscriptions without signing in again.

Pro Tip: I add the permission check to server hardening scripts. It takes a few lines, and it catches the one Linux box where someone ran chmod -R 777 to “fix” a permissions error.

Remove Stored Credentials the Right Way

There are three levels of cleanup. Pick the one that matches the situation.

Sign Out of the Current Account

az logout

az logout removes the signed-in account from the local CLI state. Use it at the end of every session on shared machines. It is the right default habit.

Clear All Cached Accounts

bashaz account clear

This removes all subscriptions and cached accounts from the CLI. It is stronger than logout when more than one identity has been used. There is a deeper walkthrough in the az account clear article.

Handle Stale or Broken Tokens

If the CLI keeps using an old identity or throws token errors, read how to refresh credentials in Azure CLI. On Windows, the error “Key not valid for use in specified state” often means the encrypted cache cannot be decrypted.

That happens when you switch between a normal and an elevated session, or when the profile changes. Run az account clear, delete the stale msal_token_cache files, and sign in again.

Warning: deleting files in .azure signs you out and removes saved defaults. It does not delete any Azure resources. Back up your config file first if you customized it.

Revoke Tokens When a Device Is Lost

Deleting local files is not enough if someone already copied them. For a lost laptop, an admin should revoke the user’s sessions in Entra ID:

az rest --method post \
  --url "https://graph.microsoft.com/v1.0/users/<user-object-id>/revokeSignInSessions"

This Microsoft Graph call invalidates refresh tokens for the user, forcing a new sign-in. The caller needs suitable directory permissions. Also reset any service principal secrets that were cached on that device. Confirm the activity afterward in the Microsoft Entra ID sign-in logs.

Pro Tip: During the lost-laptop incident I mentioned earlier, revoking sessions took two minutes. Rotating the cached service principal secret took two hours, because nobody had documented where it was used. Keep that inventory.

Secure az login in Pipelines and Containers

Build agents are where credential stor