How to Fix Azure ADSTS500011 (Microsoft Azure Active Directory)

Quick Answer: The Azure ADSTS500011 error, "The reply URL specified in the request does not match the reply URLs configured for the application," indicates a mismatch between the `redirect_uri` parameter sent by your application and the Reply URLs registered in Azure AD for that application. The most likely cause is an exact string mismatch. First, identify the `redirect_uri` from the browser's network trace. Then, navigate to the Azure portal, open the application registration, and add or modify a Reply URL to precisely match the identified `redirect_uri`. This should immediately resolve the authentication failure.

What Causes This Error

The `redirect_uri` parameter in the application's authentication request (e.g., `https://myapp.com/auth/callback`) does not exactly match any of the Reply URLs configured in the Azure AD application registration.
A subtle difference exists in the Reply URL, such as a missing or extra trailing slash (`/`), case sensitivity mismatch (e.g., `https://myapp.com/Callback` vs `https://myapp.com/callback`), or protocol difference (HTTP vs HTTPS).
The application is attempting to authenticate from a development or testing environment (e.g., `http://localhost:3000`, `https://dev.myapp.com`) that has not been explicitly registered as a valid Reply URL in Azure AD.
The application's authentication library or framework is dynamically generating a `redirect_uri` that differs from the static URLs registered in Azure AD, often due to environment variables or configuration errors.
The application registration in Azure AD has been updated or recreated, but the client application's configuration has not been synchronized with the new or modified Reply URLs.

Step-by-Step Fixes

Fix 1: Synchronize Application Reply URL with Azure AD Registration

Inspect the browser's developer tools (Network tab) during the failed authentication attempt to capture the exact `redirect_uri` parameter sent in the `GET` request to `login.microsoftonline.com`.,Navigate to the Azure portal (portal.azure.com), search for 'App registrations', and select the application experiencing the error.,Under 'Manage', click on 'Authentication'. In the 'Platform configurations' section, verify the listed 'Redirect URIs'.,If the `redirect_uri` identified in step 1 is not present, click '+ Add a platform' or '+ Add URI' and add the exact URL. Ensure protocols (HTTP/HTTPS), hostnames, paths, and case sensitivity match precisely.,Save the changes. Clear your browser cache and cookies, then re-attempt the application login.

Fix 2: Address Trailing Slashes and Case Sensitivity Mismatches

Carefully compare the `redirect_uri` from your application's request with the registered Reply URLs in Azure AD for any trailing slash inconsistencies (e.g., `https://myapp.com/callback` vs `https://myapp.com/callback/`).,Check for case sensitivity differences in the path segments (e.g., `https://myapp.com/Auth/Callback` vs `https://myapp.com/auth/callback`). Azure AD is case-sensitive for paths.,Standardize the Reply URL format in both your application's configuration and Azure AD registration. It is generally recommended to omit trailing slashes unless specifically required by your application framework.,Update the Reply URL in Azure AD to match the exact format your application consistently sends. For example, if your app sends `https://myapp.com/auth/callback`, ensure that is precisely what is registered.,Test the authentication flow again after making the correction.

Fix 3: Register Development/Localhost URLs

If the error occurs during local development or testing, identify the `redirect_uri` being used by your local environment (e.g., `http://localhost:3000/signin-oidc`).,In the Azure portal, navigate to your application's 'Authentication' blade.,Under 'Platform configurations', add a new 'Redirect URI' for your development environment. For web applications, select 'Web' as the platform.,Ensure you register both `http://localhost:<port>` and `https://localhost:<port>` if your development server can use both protocols, or if your application might switch.,Save the configuration and re-run your local application to test the authentication.

Fix 4: Review Application Code and Configuration for Dynamic Redirect URIs

Examine your application's source code, specifically the authentication configuration (e.g., `appsettings.json`, environment variables, OAuth/OIDC client configuration).,Identify how the `redirect_uri` is constructed and ensure it's not dynamically changing in a way that creates unregistered URLs.,If using a framework like ASP.NET Core, verify the `CallbackPath` in `AddOpenIdConnect` or similar settings. For Node.js/Passport.js, check the `callbackURL`.,Ensure that any environment-specific `redirect_uri` values (e.g., for staging, production) are correctly set and correspond to registered URLs in their respective Azure AD app registrations.,Rebuild and redeploy your application if code changes were necessary, then retest.

Advanced Fixes

Advanced Fix 1: Troubleshooting SPA (Single-Page Application) Redirect URIs with MSAL.js

For SPAs using MSAL.js, ensure that the `redirectUri` configured in `Msal.UserAgentApplication` or `Msal.PublicClientApplication` matches an 'SPA' platform configuration in Azure AD.,Verify that `postLogoutRedirectUri` is also correctly registered if your application handles logout redirects, as this can also cause similar errors.,Check for issues with hash-based routing (`#`) in your SPA framework. MSAL.js typically requires `https://your-app.com/` as the redirect URI, with MSAL handling the hash fragments internally. Ensure your Azure AD registration reflects this base URL.

FAQs

Q: What is a Reply URL (Redirect URI) and why is it critical?

A: A Reply URL, also known as a Redirect URI, is the exact endpoint where Azure AD will send the authentication response (e.g., security tokens) after a user has successfully authenticated. It's critical for security because it prevents tokens from being sent to unauthorized locations, ensuring that only your registered application can receive the authentication flow results. Azure AD enforces an exact match for this security measure.

Q: Can I use wildcards in Reply URLs in Azure AD?

A: No, Azure AD does not support wildcard characters (e.g., `*`) in Reply URLs for security reasons, except for specific cases with `localhost` for development purposes (e.g., `http://localhost`). Each Reply URL must be explicitly and fully defined. If you need to support multiple subdomains or paths, each one must be added as a separate, distinct Reply URL in the application registration.

Q: Does the ADSTS500011 error affect all users or specific scenarios?

A: This error typically affects all users attempting to authenticate through the misconfigured application, as the Reply URL mismatch is a fundamental configuration issue. It can manifest in specific scenarios if the application uses different `redirect_uri` values for different authentication flows (e.g., silent renewal, interactive login) or environments (e.g., development vs. production) where only some are incorrectly configured.

Q: How can I quickly identify the incorrect Reply URL being sent by my application?

A: The most effective way is to use your browser's developer tools. Open the 'Network' tab, initiate the login, and look for the `GET` request to `login.microsoftonline.com`. The full URL will contain the `redirect_uri` parameter. Copy this exact value. Alternatively, the Azure ADSTS500011 error page itself often includes the `redirect_uri` that was sent, embedded within the error details.