AADSTS50011 - Invalid Reply URL
Azure AADSTS50011 is a security mismatch error indicating that the Redirect URI (Reply URL) sent by the application does not exactly match any of the URIs registered in the Microsoft Entra app registration.
Last reviewed: April 2, 2026|Editorial standard: source-backed technical guidance
What Does Invalid Reply URL Mean?
AADSTS50011 occurs when Entra ID acts as a security gatekeeper. When your app sends a sign-in request, it specifies where the token should be sent back (redirect_uri). If this URI does not match the registered list in the App Registration character-for-character, Entra ID blocks the request to prevent token hijacking. Entra ID is strictly literal; it does not allow for close-enough matches.
Common Causes
- -Character Mismatch: Difference in a trailing slash (
.../callbackvs.../callback/). - -Protocol Discrepancy: Using
httpon a local machine while the Azure registration only hashttps. - -Port Confusion: App running on port
:3000locally but registered as:5000in the portal. - -Wrong App Registration: The client ID in the request points to App A, but you are editing the Redirect URIs for App B.
- -Wildcard Restrictions: Using wildcards in URIs for SPA or Web platforms, which Microsoft has largely restricted for security.
How to Fix Invalid Reply URL
- 1Check the Browser URL: Look at the
redirect_uri=parameter in the error page URL. Copy that exact string. - 2Ensure Character Parity: Paste that string into Entra ID > App Registration > Authentication as a new entry.
- 3Verify Platform Type: If you are building a React/Vue app, ensure the URI is under the
SPAsection, notWeb. - 4Sync Env Vars: Double-check that your
.envfile uses the exact same string as the Azure Portal.
Step-by-Step Diagnosis for Invalid Reply URL
- 1Decode the
redirect_uriparameter from the failing auth request URL. - 2Open the Microsoft Entra admin center and navigate to the Authentication blade of the app.
- 3Compare sent versus registered URIs side-by-side, focusing on the scheme, port, and path.
- 4Verify the
clientIdmatches the registration you are currently auditing.
The Literal Match Rule
- -HTTP vs HTTPS: These are considered completely different origins.
- -Trailing Slash:
.../authand.../auth/are not interchangeable. - -Case Sensitivity: While DNS is not case-sensitive, the path and query string in Redirect URIs are.
Implementation Examples
// App sends this (from browser address bar):
"http://localhost:3000/api/auth/callback/azure"
// Azure Portal must have exactly this:
"http://localhost:3000/api/auth/callback/azure"How to Verify the Fix
- -Restart the sign-in flow and confirm the browser redirects back to the app without an error.
- -Check the Network tab (F12) for a successful 302 redirect to the expected callback path.
- -Confirm that Staging and Prod environments have their own distinct URIs registered.
How to Prevent Recurrence
- -Use IaC: Manage Redirect URIs via Terraform or Bicep to eliminate manual entry errors.
- -Dynamic Config: Read the Redirect URI from a central environment variable in your code.
- -Pro-tip: Add updating the Redirect URI to your new environment checklist to catch port or domain changes before deployment.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.