🚨 Azure Error: 'InvalidAuthenticationTokenTenant' — Cause, Fix, and Troubleshooting Guide

Overview

Azure Resource Manager returns InvalidAuthenticationTokenTenant when the bearer token presented to it was issued by a different tenant than the one that owns the resource or subscription being addressed. The token is valid — just for the wrong directory. The literal error:

{
  "error": {
    "code": "InvalidAuthenticationTokenTenant",
    "message": "The access token is from the wrong issuer 'https://sts.windows.net/11112222-3333-4444-5555-666677778888/'. It must match the tenant 'https://sts.windows.net/99998888-7777-6666-5555-444433332211/' associated with this subscription. Please use the authority (URL) 'https://login.microsoftonline.com/99998888-7777-6666-5555-444433332211' to get the token."
  }
}

The message hands you the answer: the tenant GUID the token is from, the tenant it must be from, and the exact authority URL to use.

Symptoms

• az / SDK / REST calls fail with InvalidAuthenticationTokenTenant while the same identity works against a different subscription.
• The error names two tenant GUIDs — the token’s issuer and the required one.
• Cross-tenant automation (managing subscriptions in a customer/partner tenant) fails after a login that defaulted to the home tenant.
• A service principal created in tenant A is used against a subscription that has been moved to tenant B.

Common Root Causes

• Logged into the wrong tenant — az login defaulted to your home tenant, but the target subscription lives in another directory.
• Subscription moved between tenants — a subscription transferred to a new tenant now requires tokens from that new tenant; old service principals in the old tenant no longer work.
• Multi-tenant SPN, wrong authority — a multi-tenant app must request the token from the resource tenant’s authority, not its home tenant.
• Cached token for the previous tenant — a stale token in the CLI/MSAL cache issued for the earlier tenant is being reused.
• Guest/B2B confusion — the identity is a guest in the target tenant but the token was minted against the home tenant authority.

How to diagnose

See which tenant your current context is authenticated against:

az account show --query "{subscription:name, subscriptionId:id, tenantId:tenantId}" -o json

Compare that tenantId to the tenant the error says is required. List all tenants your identity can reach:

az account tenant list --query "[].{tenantId:tenantId, name:displayName}" -o table

List the subscriptions and note which tenant each belongs to:

az account list --query "[].{name:name, id:id, tenantId:tenantId, state:state}" -o table

If a subscription’s tenantId does not match your logged-in tenant, that is the mismatch producing the error.

Fixes

Log in against the correct tenant (the one the error requires):

az login --tenant 99998888-7777-6666-5555-444433332211
az account set --subscription <subscription-id-in-that-tenant>

For a service principal, authenticate with the resource tenant as the authority:

az login --service-principal \
  --username <appId> --password <secret-or-cert> \
  --tenant 99998888-7777-6666-5555-444433332211

In an SDK (DefaultAzureCredential / ClientSecretCredential), pass the target tenant id explicitly and, if the identity is multi-tenant, allow the cross-tenant authority:

from azure.identity import ClientSecretCredential
cred = ClientSecretCredential(
    tenant_id="99998888-7777-6666-5555-444433332211",  # resource tenant
    client_id="<appId>",
    client_secret="<secret>",
)

Clear stale cached tokens if a previous tenant’s token is being reused:

az logout
az account clear
az login --tenant <required-tenant-id>

What to watch out for

• The error already contains the fix. The authority (URL) in the message is exactly what to pass as --tenant / authority.
• Subscription moves invalidate old SPNs. After a subscription transfers tenants, recreate service principals and role assignments in the new tenant — the old tenant’s principals will keep failing this check.
• Multi-tenant apps need admin consent in the resource tenant before their token is accepted there.
• az account set after login. Switching tenants without also selecting a subscription in that tenant leaves you targeting the wrong context.

Related

• ExpiredAuthenticationToken — a valid-tenant token that has simply aged out.
• DefaultAzureCredential failed to retrieve a token — SDK credential-chain failures, including tenant misconfiguration.
• AADSTS700016 / AADSTS50076 — app-not-found and MFA sign-in errors from the same Entra ID layer.