AADSTS50011 Reply URL Mismatch: Microsoft Entra Fix

An AADSTS50011 reply URL mismatch means Microsoft Entra received a callback address from an application that did not match the callback addresses configured for that application. The reliable fix is to capture the exact URL and application ID from the failed request, decide whether the flow is OAuth/OpenID Connect or SAML, and then correct the matching configuration surface. Do not start by resetting the user's password, excluding the user from Conditional Access, or adding a broad wildcard.

Grab a coffee and keep the full error page open. The URL and application ID in that page are evidence, not decoration. For OAuth 2.0 or OpenID Connect, compare the request's redirect_uri with the redirect URIs on the app registration. For SAML, compare the AuthnRequest's AssertionConsumerServiceURL with the Reply URL (Assertion Consumer Service URL) on the enterprise application's SAML configuration. Microsoft documents both variants of the same error separately, and the repair surface is different for each protocol: OIDC/OAuth AADSTS50011 troubleshooting and SAML AADSTS50011 troubleshooting.

This guide is for administrators and application owners diagnosing an AADSTS50011 reply URL mismatch in a workforce tenant. It focuses on preserving the security boundary while fixing the smallest incorrect value.

AADSTS50011 reply URL mismatch: classify the flow first

The error text can say either reply URL or redirect URI. Those names overlap, but the protocol tells you where to look.

• OAuth 2.0 or OpenID Connect: look for /authorize, redirect_uri, response_type=code, or OIDC metadata. Entra compares redirect_uri; inspect Entra ID > App registrations > [app] > Authentication.
• SAML 2.0: look for SAMLRequest, AuthnRequest, Entity ID, or ACS. Entra compares AssertionConsumerServiceURL; inspect Entra ID > Enterprise apps > [app] > Single sign-on > SAML > Basic SAML Configuration.
• OAuth/OIDC native app: a public-client or broker callback belongs under the app registration's Mobile and desktop applications, iOS/macOS, or Android platform.
• OAuth/OIDC browser app: a callback generated by MSAL.js normally belongs under the app registration's Single-page application platform.

Microsoft describes a redirect URI as the destination to which the authorization service returns the browser and security response after authorization. Entra only redirects to an address registered for the application because sending an authorization code or token to an unapproved location would create an interception path. The redirect-URI reference explains the matching boundary and its security purpose.

That gives you the first incident rule: do not make the registered list broader than the application actually needs. The objective is not to make the error disappear at any cost. The objective is to make the request and one approved callback address agree.

What the error proves—and what it does not

For OIDC and OAuth, Microsoft says Entra compares the redirect URI sent by the application with the redirect URI values on the registered application. If none match, Entra returns AADSTS50011; if one matches, Entra can return the browser to that address. Microsoft's error reference documents that comparison directly.

For SAML, the comparison is between the AssertionConsumerServiceURL in the SAML AuthnRequest and the Reply URL or accepted pattern in the enterprise application's SAML configuration. Microsoft's SAML error reference identifies the ACS mismatch as the cause.

The error does not prove that:

• the user's password or MFA method is wrong;
• Conditional Access should be disabled;
• the application's client secret expired;
• the user lacks assignment to the application;
• DNS propagation is the primary problem;
• adding the displayed URL is always the right fix.

That last point matters. Microsoft explicitly notes that if the application is sending an undesired redirect URI, the correct repair is in the application's code or configuration—not in Entra. Registering a backend hostname, an HTTP callback, an abandoned staging site, or an attacker-controlled address merely because it appeared in an error can turn a configuration incident into a security defect.

Step 1: preserve the failed request before changing anything

Capture the following from the user's error page:

1. the complete redirect or reply URL, including scheme, host, port, path, case, trailing slash, and query string;
2. the application or client ID shown in the message;
3. timestamp, request ID, correlation ID, tenant, and username;
4. the entry point the user selected—a bookmark, My Apps tile, vendor URL, or application-generated sign-in button;
5. whether the failure affects production, staging, one hostname, one region, or every user.

For an OIDC/OAuth flow, the browser's authorization request contains redirect_uri. Capture the actual request generated by the affected environment rather than copying a value from deployment documentation. A reverse proxy or application runtime can construct a different address at execution time.

For SAML, capture the AuthnRequest and read its AssertionConsumerServiceURL. Microsoft's SAML debugging guidance recommends examining the request when the company sign-in page reports an error and checking the ACS destination against the Entra configuration. The SAML debugging procedure explains which request fields to inspect.

Do not paste authorization codes, tokens, session cookies, or full SAML assertions into a ticket. The callback address, application ID, request identifiers, and timestamp are normally sufficient for this diagnosis.

Step 2: make sure you have the right application object

The application ID in the error is the safest lookup key. Display names are not unique, and tenants often contain similarly named production, staging, and vendor applications.

For OAuth/OIDC:

1. Open Entra ID > App registrations > All applications.
2. Search for the Application (client) ID from the error.
3. Open Authentication.
4. Inspect every platform section: Web, Single-page application, Mobile and desktop applications, iOS/macOS, or Android.

Microsoft's current resolution procedure follows this same application-ID-first path and says to use the app registration's Authentication page. The official AADSTS50011 repair steps identify the correct object and portal location.

Do not add OAuth/OIDC redirect URIs to the service principal. Microsoft says redirect URI values belong on the application object and warns that values placed on a service principal can be removed when it synchronizes from the application object. The application-model restrictions document this object boundary.

For SAML:

1. Open Entra ID > Enterprise apps > All applications.
2. Find the enterprise application for the failed integration.
3. Open Single sign-on > SAML.
4. Edit Basic SAML Configuration and inspect Reply URL (Assertion Consumer Service URL).

The SAML Reply URL is not the same field as the Sign on URL or Identifier (Entity ID). Microsoft's SAML configuration guide defines the Reply URL as the ACS destination and treats the Sign on URL as the address used to initiate the application journey. The SAML setup guide keeps those values separate.

Step 3: compare the URI as structured data

Put the requested and registered values beside each other. Compare them component by component instead of reading them as one long string.

Requested:  https://app.contoso.com/finance/signin-oidc
Registered: https://app.contoso.com/Finance/signin-oidc
                                   ^ path case differs

Check these boundaries in order:

• Scheme: https and http are different. Production HTTP redirect URIs are not accepted for normal web applications; HTTP is limited to localhost development scenarios.
• Host: app.contoso.com, www.contoso.com, a platform hostname, and an internal backend hostname are different destinations.
• Port: non-localhost ports are part of the match. :443, :8443, and an omitted port are not interchangeable assumptions.
• Path: /signin-oidc, /auth/callback, and /oauth2/callback are different paths. Path case is significant.
• Trailing slash: a root URI has documented trailing-slash behavior, while a URI with a path segment is not automatically given a slash.
• Query: query parameters have audience-dependent support and must not be treated as an informal wildcard mechanism.
• Platform type: a Web callback registered only under SPA—or the reverse—can produce the wrong response behavior even when the text looks familiar.

Microsoft's restrictions page confirms the HTTPS requirement, path case sensitivity, root trailing-slash behavior, localhost exception, and audience-dependent query-string support. Use the documented redirect-URI rules rather than trial and error.

Localhost is a special case. Entra ignores the port when matching localhost redirect URIs for native development scenarios, so registering several localhost values that differ only by port does not create deterministic platform selection. Microsoft recommends differentiating test callbacks by path and documents that the IPv6 loopback address is not supported. The localhost rules explain the matching exception.

Step 4: decide which side is wrong

There are only two legitimate repair directions:

The requested URI is correct

Use this path when the URL is the approved, reachable callback for the deployed application and the omission in Entra is the defect.

For OAuth/OIDC, add the exact URI to the correct platform on the app registration. Microsoft provides separate platform choices for server-side web apps, browser-based SPAs, native mobile/desktop apps, iOS/macOS, and Android. The add-redirect-URI guide maps application type to platform configuration.

For SAML, add or correct the exact vendor-provided ACS address in the enterprise application's Basic SAML Configuration. The application's metadata or vendor configuration should be the authority for that value. Do not substitute the Sign on URL or Entity ID because it happens to be on the same page.

The requested URI is wrong

Use this path when the request contains a backend address, obsolete hostname, incorrect case, development callback, HTTP scheme, wrong tenant environment, or unexpected path.

Correct the application configuration or the infrastructure that generated the request. Common sources include:

• an environment variable copied from staging into production;
• a redirect URI hard-coded for the wrong region;
• a reverse proxy that does not forward the original host or scheme;
• a load balancer that terminates TLS while the backend believes the request is HTTP;
• a path prefix added by an ingress but omitted by the application;
• a vendor-side ACS URL changed during a domain migration;
• a user entering through an obsolete bookmark that selects another client ID.

Behind a proxy or gateway, the public callback—not the private backend address—normally belongs in the app registration. Microsoft documents that missing or incorrectly processed forwarded headers can cause an application to generate a localhost, HTTP, backend-host, or path-incomplete redirect URI. Its ASP.NET Core guidance requires forwarded headers to be processed before authentication and HTTPS redirection. The proxy deployment guide shows the failure pattern and middleware order.

Step 5: avoid the tempting unsafe fixes

Wildcard redirect URIs reduce the value of the callback allowlist. Microsoft strongly recommends exact absolute URIs and describes wildcard matching as a security risk; wildcard support is also restricted by sign-in audience. If many subdomains need to return to one application, Microsoft's documented alternative is one shared redirect endpoint plus a protected state value that maps to application state. The redirect-URI guidance explains both wildcard risk and the state pattern.

Also avoid these shortcuts:

• registering every hostname seen in logs;
• adding production and development callbacks to one app without an ownership reason;
• changing the app from Web to SPA just to make a test pass;
• editing both the application and Entra simultaneously, which destroys the evidence of which side was wrong;
• deleting all existing reply URLs before recording them;
• copying a SAML ACS value into an OAuth platform section;
• confusing AADSTS50011 with AADSTS500011, which is a different error about a missing resource principal.

Separate app registrations for development, staging, and production reduce accidental cross-environment callback exposure. Microsoft recommends removing unnecessary development redirect URIs from production and explicitly suggests separate registrations for development and production. That environment guidance appears in the redirect-URI overview.

Inventory redirect URIs with Microsoft Graph

For OAuth/OIDC applications, a read-only Graph inventory is useful when the portal hides the difference between platform collections or when several environments share an owner. The v1.0 application object stores redirect URIs separately under web, spa, and publicClient.

Import-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.Read.All"

$clientId = "00000000-0000-0000-0000-000000000000"
$app = Get-MgApplication -Filter "appId eq '$clientId'" `
  -Property "id,appId,displayName,web,spa,publicClient"

[pscustomobject]@{
  DisplayName          = $app.DisplayName
  AppId                = $app.AppId
  ObjectId             = $app.Id
  WebRedirectUris      = $app.Web.RedirectUris -join "`n"
  SpaRedirectUris      = $app.Spa.RedirectUris -join "`n"
  PublicRedirectUris   = $app.PublicClient.RedirectUris -join "`n"
} | Format-List

This command reads the application object; it does not modify it. Microsoft's v1.0 application resource model defines those three redirect URI collections, and the update API can address an application by object ID or app ID.

Be careful when automating a repair. Redirect URIs are collections. Build the intended complete collection from a fresh read, review the diff, and then update only after you understand the SDK's serialization behavior. A one-line write that replaces a collection can remove working callbacks for other environments. For a single incident, the portal's platform-specific editor is usually the safer change surface.

Validate the fix without widening the incident

Microsoft says to allow three to five minutes after changing an OIDC redirect URI before retrying. Use that window to document the before-and-after values and confirm that the intended callback resolves to the expected application. The official resolution gives the propagation interval.

Then test in this order:

1. Start from the application's canonical production entry point, not an old bookmark.
2. Use a private browser session so an old authorization request or cached application route does not confuse the result.
3. Confirm the authorization request now carries the intended callback.
4. Complete one sign-in with a low-risk pilot account assigned to the application.
5. Confirm the browser returns to the expected HTTPS host and path.
6. Confirm the application validates the response and creates a session; a new application-side error means the redirect mismatch is fixed and the next control plane now needs attention.
7. Repeat the specific launch modes you support: app-initiated, My Apps, deep link, regional hostname, and sign-out callback where applicable.

For SAML, use the enterprise application's Test single sign-on experience and the vendor's supported SP-initiated entry point. A successful IdP-initiated test does not automatically prove that every SP-initiated request sends the same ACS URL.

Do not delete the previous working URI in the same change that adds a replacement unless the cutover is atomic and tested. Add the approved replacement, validate the new route, move traffic, and then remove the obsolete URI in a separately reviewed cleanup. That preserves a clean rollback while avoiding a permanent collection of abandoned callbacks.

Troubleshoot by the first mismatch

Use this compact flow when the error returns:

1. The application ID is unexpected: the user reached the wrong environment, tenant-specific link, or app registration. Correct the launch path before changing URLs.
2. The application ID is correct but the scheme or host is wrong: inspect application base-URL settings, forwarded headers, TLS termination, and proxy host preservation.
3. The host is correct but the path differs: check callback-path configuration, ingress path rewriting, application base paths, and case.
4. The URI text matches but the platform is wrong: register it under the actual Web, SPA, or native-client platform and verify the application's OAuth flow.
5. SAML ACS differs: obtain the current ACS from vendor metadata or the service provider and update only the Reply URL field.
6. The new URI works for one launch mode only: capture a fresh request from each failing entry point; one path is generating a different callback.
7. The error persists after an approved change: wait the documented propagation interval, start a fresh private session, and prove which app ID and URI the new request actually sends.

If the error changes, stop troubleshooting AADSTS50011. For example, AADSTS50020 is an external-identity and tenant-resolution problem, while AADSTS53003 points to a Conditional Access block. A new error code is evidence that the request progressed to another boundary.

AADSTS50011 administrator checklist

• Capture the exact URI, application ID, timestamp, request ID, and correlation ID.
• Identify OAuth/OIDC versus SAML before opening a configuration blade.
• Locate the application by ID, not display name.
• Compare scheme, host, port, path, case, slash, query, and platform.
• Decide whether the request or the registered value is wrong.
• Fix proxy and application generation when the requested URI is unsafe or unintended.
• Add only an approved exact callback; do not use a wildcard as an incident shortcut.
• Keep development and production callbacks separated where practical.
• Record the old and new values and preserve a rollback path.
• Wait three to five minutes for an OIDC app-registration change, then retest from a private session.
• Validate every supported launch mode and remove obsolete callbacks in a reviewed cleanup.

The deeper architecture is covered in the site's guide to SAML, WS-Fed, OAuth, and OpenID Connect. If the callback succeeds but the application then mishandles its token or session, continue with the access-token and refresh-token trust-boundary guide rather than reopening the redirect URI list.

The short version is pleasantly boring: trust the failed request, find the correct object, compare the complete callback, and change the side that is actually wrong. AADSTS50011 is strict because redirect destinations are a security boundary. Keep the fix just as strict.