AADSTS90002 - Invalid Tenant Name
Microsoft Entra ID returns `AADSTS90002` when the tenant identifier in the auth request cannot be found or resolved.
Last reviewed: April 6, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Invalid Tenant Name Mean?
Authentication requests cannot be routed to a valid tenant directory, so token issuance halts before user or app validation.
Common Causes
- -Tenant ID or domain is mistyped, malformed, or references a non-existent directory.
- -Application targets wrong cloud endpoint for the tenant (for example public cloud versus national cloud mismatch).
- -Authority URL is configured with stale tenant value after tenant migration or split.
- -App registration and requested tenant context do not match expected sign-in audience.
How to Fix Invalid Tenant Name
- 1Validate tenant identifier directly in Entra and copy canonical tenant ID/domain into config.
- 2Use tenant-specific authority endpoint instead of generic endpoint when app is single-tenant.
- 3Verify cloud instance and authority host align with where tenant actually exists.
- 4Retry token acquisition after correcting tenant identifier and authority values.
Step-by-Step Diagnosis for Invalid Tenant Name
- 1Capture auth request URL and confirm tenant segment used in token endpoint call.
- 2Check app registration signInAudience and tenant ownership against request context.
- 3Verify tenant domain is registered and available in the targeted cloud instance.
- 4Replay with explicit known-good tenant ID to isolate config drift in runtime environment.
Tenant Identifier and Authority Validation
- -Compare configured tenant ID/domain with Entra portal canonical value (example: stale copied tenant domain from decommissioned directory).
- -Validate authority host and cloud alignment (example: public cloud login endpoint used for tenant that exists only in sovereign cloud).
App Registration and Audience Alignment
- -Inspect app registration tenancy model (example: single-tenant app queried through
/commonendpoint with unsupported flow). - -Audit environment configuration inheritance (example: fallback tenant value from shared config overrides service-specific tenant setting).
Seen in Production
Service migrated to new tenant but old tenant ID remained in environment config
Frequency: common
Example: Token requests fail with AADSTS90002 immediately after deployment.
Fix: Update tenant ID and authority endpoint across all runtime and CI secrets.
App deployed to sovereign cloud using public cloud login endpoint
Frequency: rare
Example: Tenant cannot be found because request goes to wrong cloud authority.
Fix: Switch authority host to matching national cloud endpoint and retest token flow.
Debugging Tools
- -Entra sign-in and token logs
- -Authority URL/tenant config trace
- -App registration metadata inspection
- -Cloud endpoint validation checks
How to Verify the Fix
- -Request token again and confirm
AADSTS90002is resolved. - -Validate downstream API calls succeed with tokens issued from the corrected tenant.
- -Confirm auth telemetry no longer shows tenant-resolution failures for the workload.
How to Prevent Recurrence
- -Store tenant identifiers as immutable environment metadata with change review gates.
- -Validate authority URL and cloud instance in CI before deploying auth-related changes.
- -Run periodic auth health probes that resolve tenant and request real tokens safely.
Pro Tip
- -include tenant fingerprint checks in startup diagnostics and fail fast when runtime tenant differs from approved manifest.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.