Azure and Entra ID "AADSTS" errors: what the most common codes mean, and how to fix them

1. MFA and expired sessions (50076, 700082)

These tell you that a person has to sign in, and a script or an old session can’t. In the Azure CLI:

az logout
az login
az login --tenant 11111111-2222-3333-4444-555555555555
az account show

Is the Azure CLI on a machine with no browser? Use az login --use-device-code.

Passing -u and -p to az login doesn’t work for accounts with MFA. As of 2025, Microsoft requires MFA for all sign-ins to the Azure portal, CLI, and PowerShell, so a script that uses a person’s password will stop working. Automation should use a service principal or a managed identity, not a person’s account:

az login --service-principal --username "$APP_ID" --password "$SECRET" --tenant "$TENANT_ID"
az login --identity          # on an Azure VM with a managed identity

In a pipeline, workload identity federation is better still, as there’s no secret to store or expire.

2. App not found (700016)

AADSTS700016: Application with identifier 'abc...' was not found in the directory 'Contoso'.

Check these, in order:

• The wrong tenant. Is the app registered in a different one? A common cause is /common or a wrong tenant ID in the URL.
• A typo in the client ID. You want the Application (client) ID, and not the Object ID, which is also a GUID on the same page.
• It’s an app from another tenant that hasn’t been added to yours. An administrator needs to consent first (section 4).
• It’s been deleted, or hasn’t reached every server yet, if it’s only just been created.

az ad app show --id "$APP_ID" --query '{name:displayName, audience:signInAudience}'
az ad sp show --id "$APP_ID" --query displayName

3. Client secret (7000215, 7000222)

AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID

The message gives the classic mistake away. The portal shows two columns under Certificates & secrets, Value and Secret ID, and you need the Value. It’s only shown once, when you create it. So, if you didn’t save it, make a new one:

az ad app credential reset --id "$APP_ID" --append --display-name ci-2026
az ad app credential list --id "$APP_ID" --query '[].{name:displayName, ends:endDateTime}'

7000222 means it has expired, so the same command applies, and --append keeps the old one working during the change. Set a reminder for the new end date. Check special characters too: a secret passed through a shell or a YAML file without quotes can get changed on its way.

4. Reply URL and consent (50011, 65001)

AADSTS50011: The redirect URI 'https://app.example.com/callback' specified in the request does not match the redirect URIs configured for the application

The URL must match exactly what’s registered, under Authentication, including https, the port, the path, and any trailing /. Behind a proxy, your application may build it as http://, or with an internal address, so look at the value in the error, and fix your forwarded headers if needed.

AADSTS65001: The user or administrator has not consented to use the application

Someone has to approve the app’s permissions. A user can do so for their own use, if the tenant allows that. Otherwise, an administrator grants consent for the whole tenant under API permissions → Grant admin consent:

az ad app permission admin-consent --id "$APP_ID"

5. Conditional Access (53003)

AADSTS53003: Access has been blocked by Conditional Access policies.

Your organization’s policy refused this sign-in, based on where it’s from, the device or the app. You can’t solve this one yourself, so give your administrator the Correlation ID and Timestamp. They’ll find the attempt under Entra ID → Sign-in logs, and its Conditional Access tab shows which policy applied. The usual reasons are an unmanaged device, or a location outside the allowed list.

6. See what’s in your token

If you’re signing in, and a service still refuses you, look at the token. Get one, and paste it in the JWT Decoder, which runs in your browser:

az account get-access-token --query accessToken -o tsv

Look at aud (who it’s for), tid (the tenant), scp or roles (what it allows) and exp. A token for the wrong audience or tenant is a common cause of a 401 or 403 from an API. For expired tokens, see jwt expired. A clock that’s wrong on your machine can give AADSTS700024 and others, so check that too.