What causes AADSTS700005?

Authorize request hits `/common` or `/organizations`, but the token request hits a specific `/{tenant-id}` (or vice versa) without using the `tid` claim from the ID token. Multi-tenant app hardcodes a tenant ID in the token endpoint while letting the user pick a tenant at sign-in. Guest/B2B user signs in to their home tenant but the app redeems against the resource tenant. Cached or stale authorization code from a previous tenant context being replayed (e.g. after tenant switch in Power BI Service). Reverse proxy, load balancer, or auth library rewriting the authority between the two OAuth legs

How do I fix AADSTS700005?

Capture both the `/authorize` and `/token` request URLs (Fiddler, browser devtools, or app logs) and confirm the tenant segment is identical — this is the root cause in ~90% of cases. If your app is multi-tenant, parse the `tid` claim from the returned ID token and use that exact tenant ID in the `/token` redemption call instead of `/common`. In the Microsoft Entra admin center, verify the app registration's **Supported account types** matches your flow (single-tenant vs multi-tenant vs personal accounts). For Power BI embedded or service principal scenarios, ensure `MSAL` / `ADAL` is initialized with the same authority string used during user sign-in — don't switch between `common` and tenant-specific authorities mid-flow. Clear any cached authorization codes and retry with a fresh sign-in; authorization codes are single-use and tenant-bound

Low severityauthentication

Power BI Error:
AADSTS700005

What does this error mean?

OAuth2 authorization code was issued for one Microsoft Entra ID (Azure AD) tenant but redeemed against a different tenant.

Common causes

1Authorize request hits `/common` or `/organizations`, but the token request hits a specific `/{tenant-id}` (or vice versa) without using the `tid` claim from the ID token
2Multi-tenant app hardcodes a tenant ID in the token endpoint while letting the user pick a tenant at sign-in
3Guest/B2B user signs in to their home tenant but the app redeems against the resource tenant
4Cached or stale authorization code from a previous tenant context being replayed (e.g. after tenant switch in Power BI Service)
5Reverse proxy, load balancer, or auth library rewriting the authority between the two OAuth legs

How to fix it

1Capture both the `/authorize` and `/token` request URLs (Fiddler, browser devtools, or app logs) and confirm the tenant segment is identical — this is the root cause in ~90% of cases
2If your app is multi-tenant, parse the `tid` claim from the returned ID token and use that exact tenant ID in the `/token` redemption call instead of `/common`
3In the Microsoft Entra admin center, verify the app registration's **Supported account types** matches your flow (single-tenant vs multi-tenant vs personal accounts)
4For Power BI embedded or service principal scenarios, ensure `MSAL` / `ADAL` is initialized with the same authority string used during user sign-in — don't switch between `common` and tenant-specific authorities mid-flow
5Clear any cached authorization codes and retry with a fresh sign-in; authorization codes are single-use and tenant-bound

Frequently asked questions

What does AADSTS700005 mean?

Provided Authorization Code is intended to use against other tenant, thus rejected. OAuth2 Authorization Code must be redeemed against same tenant it was acquired for (/common or /{tenant-ID} as appro

How do I fix this error?

Check your application registration, token configuration, and user permissions in the Azure portal. Review Conditional Access policies if the error is policy-related.

Source · learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes#aadsts-error-codes