AADSTS90002 - Invalid Tenant Name
Microsoft Entra ID returns `AADSTS90002` when the tenant identifier in the auth request cannot be found or resolved.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
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 `/common` endpoint with unsupported flow).
- -Audit environment configuration inheritance (example: fallback tenant value from shared config overrides service-specific tenant setting).
How to Verify the Fix
- -Request token again and confirm `AADSTS90002` is 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.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.