Microsoft Entra ID: AADSTS50011, the redirect URI specified in the request does not match the redirect URIs configured for the application

Hi, it's BlueByte. A user clicks Sign in with Microsoft, gets the familiar login page, types the right password — and instead of landing back in the app, gets a Microsoft error page: AADSTS50011: The redirect URI 'https://app.contoso.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application '11111111-2222-3333-4444-555555555555'. The account is fine and the credentials were accepted; authentication ran to completion and Entra ID refused only the final hop back to your app. We'll walk through the wordings this error comes in, the mismatches that actually cause it, how to read the failing request instead of guessing, how to add the URI from the command line, and how to keep the next hostname from doing the same thing.

Two wordings of AADSTS50011, and the two facts each one hands you

Microsoft's troubleshooting article for this code gives the current text:

Error AADSTS50011 - The redirect URI <Redirect URI> specified in the request does not
match the redirect URIs configured for the application <AppGUID>. Make sure the redirect
URI sent in the request matches one added to your application in the Azure portal.
Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

Older libraries and older tenants surface the same failure with the previous vocabulary: AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application. "Reply URL" was the portal's earlier name for the same field. The error-code reference lists 50011 under its internal name as well, InvalidReplyTo - The reply address is missing, misconfigured, or doesn't match reply addresses configured for the app.

Whichever wording you get, it hands you the two facts the rest of this article compares: the exact URI your application sent, and the application ID it was checked against. Copy both out of the page before you close it.

The mismatches that actually cause it: case, trailing slash, scheme, port

Entra compares the redirect_uri in the authorization request against the registered list as a string, under rules the redirect-URI documentation states plainly. These are the ones that bite in practice:

• Case matters. Redirect URIs are case-sensitive and must match the case of the URL path of your running application, so .../abc/response-oidc is not .../ABC/response-oidc.
• Trailing slashes are not symmetric. A URI registered with no path segment is returned with a trailing slash when the response mode is query or fragment — https://contoso.com comes back as https://contoso.com/. A URI that does contain a path segment is not given one.
• The scheme must be https, with an exception only for localhost. The docs mark http://contoso.com/abc/response-oidc invalid, while http://localhost, http://localhost/abc and https://localhost are all valid.
• The port is ignored only for localhost. http://localhost:1234/MyApp and http://localhost:8080/MyApp are documented as equivalent. Anywhere else the port is part of the match, so https://app.contoso.com:8443/signin-oidc is a different URI from https://app.contoso.com/signin-oidc.
• Some characters are rejected outright: ! $ ' ( ) , ; are not supported, and neither are internationalized domain names.
• Query parameters depend on the audience. They are allowed for registrations that sign in work or school accounts, and not allowed for any registration configured for personal Microsoft accounts.

The IPv6 loopback [::1] is not currently supported either, which catches dev machines where a tool binds ::1 instead of 127.0.0.1. None of this needs memorizing — it just means the comparison is stricter than you expect, so compare strings rather than eyeballing them.

The other half: the right URI on the wrong platform, or on the wrong object

A URI can be present in the registration and still not match, because a registration keeps three separate lists. In the Microsoft Graph application resource they are web (a server-rendered app), spa (a single-page app — JavaScript, Angular, React, Blazor WebAssembly, Vue.js) and publicClient (mobile and desktop). Microsoft's platform tables map each framework to the list it belongs in, and a React app whose URI was added under Web is a common way to get 50011 from a registration that visibly contains the URI.

The second trap is which object holds it. The docs are blunt: always add redirect URIs to the application object only, and never to a service principal, because those values can be removed when the service principal object syncs with the application object. A URI added on the enterprise-application side can work for weeks and then quietly vanish.

Compare the sent URI with the registered list before touching anything

Pull the URI your app actually sent out of the failed /authorize request (the browser's Network tab keeps it), then read every list on the registration:

python3 -c "import sys,urllib.parse as u; q=u.parse_qs(u.urlparse(sys.argv[1]).query); print(q['redirect_uri'][0])" \
  'https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize?client_id=11111111-2222-3333-4444-555555555555&response_type=code&redirect_uri=https%3A%2F%2Fapp.contoso.com%2Fsignin-oidc'
 
az ad app show --id 11111111-2222-3333-4444-555555555555 \
  --query "{web: web.redirectUris, spa: spa.redirectUris, publicClient: publicClient.redirectUris, audience: signInAudience}"

https://app.contoso.com/signin-oidc

{
  "audience": "AzureADMyOrg",
  "publicClient": [],
  "spa": [],
  "web": [
    "https://app.contoso.com/signin-oidc/"
  ]
}

Then stop reading and let diff do it, because a trailing slash is exactly the kind of thing eyes skip:

diff <(printf '%s\n' 'https://app.contoso.com/signin-oidc') \
     <(az ad app show --id 11111111-2222-3333-4444-555555555555 --query "web.redirectUris" -o tsv)

1c1
< https://app.contoso.com/signin-oidc
---
> https://app.contoso.com/signin-oidc/

An empty web list with a populated spa list (or the reverse) is the platform problem instead. An audience of AzureADandPersonalMicrosoftAccount is your warning that query parameters and wildcards are off the table for this registration.

Write the exact string back with az ad app update, or a Graph PATCH for a SPA

--web-redirect-uris replaces the whole list rather than appending to it, so read the current values first and write them back together with the new one:

az ad app show --id 11111111-2222-3333-4444-555555555555 --query "web.redirectUris" -o tsv

https://contoso-stg.azurewebsites.net/signin-oidc

Then pass every URI you want to keep, plus the new one, in a single command. Spell them out rather than piping the previous output into the next command — anything you leave off the line is deleted from the registration:

az ad app update --id 11111111-2222-3333-4444-555555555555 \
  --web-redirect-uris https://contoso-stg.azurewebsites.net/signin-oidc \
                      https://app.contoso.com/signin-oidc

The CLI has no flag for the SPA list, so go at the application object through Microsoft Graph. Note that the Graph URL takes the object ID, not the application ID:

OBJ=$(az ad app show --id 11111111-2222-3333-4444-555555555555 --query id -o tsv)
az rest --method PATCH \
  --url "https://graph.microsoft.com/v1.0/applications/$OBJ" \
  --headers "Content-Type=application/json" \
  --body '{"spa":{"redirectUris":["https://app.contoso.com/","https://app.contoso.com/auth"]}}'

The change is not instant. Microsoft's resolution steps say to save and then wait three to five minutes before sending the login request again, and to clear the browser's password cache or use an InPrivate window if the login page does not reappear. If the URI in the error was never the one you wanted, fix the application code or its configuration instead of registering the wrong value.

A worked example: staging moves behind a new hostname

A staging ASP.NET Core deployment moves from https://contoso-stg.azurewebsites.net to https://staging.contoso.com, and sign-in starts failing with AADSTS50011 naming https://staging.contoso.com/signin-oidc. If you check it yourself, az ad app show lists only https://contoso-stg.azurewebsites.net/signin-oidc under web, with spa and publicClient empty and signInAudience set to AzureADMyOrg. That rules out the platform trap and the audience restrictions in one command: the URI is simply not registered. One az ad app update writes both URIs back into web.redirectUris, and after a four-minute wait a private window completes sign-in and the callback arrives at https://staging.contoso.com/signin-oidc?code=.... Confirm it rather than assuming — re-run az ad app show --query "web.redirectUris" -o tsv and check that both lines are there, then sign out and in once more in a normal window to prove the cached login page was not doing the work.

Keep it from coming back

Give each environment its own app registration. The docs recommend exactly this, so development redirect URIs are never exposed in a production app. Know the ceilings before you start adding hostnames: 256 redirect URIs for a registration whose signInAudience is AzureADMyOrg or AzureADMultipleOrgs, 100 for AzureADandPersonalMicrosoftAccount, and 256 characters per URI, none of which can be raised.

Wildcards look like the answer to a pile of subdomains and are not. https://*.contoso.com strips query strings and fragments from the matched redirect URI, is unsupported for registrations that sign in personal Microsoft accounts, and can only be set through the manifest editor. The documented alternative is one shared redirect URI plus a state parameter carrying a key into browser storage — with CSRF protection, and without putting URLs or other sensitive data in state directly. For local development, prefer 127.0.0.1 over localhost so a renamed interface or a firewall cannot break sign-in, and never register several localhost URIs that differ only in port: the login server picks one arbitrarily, so tell them apart by path instead.

How this differs from AADSTS900971 and AADSTS700016

AADSTS900971: No reply address provided. means the request carried no redirect URI at all, which is a client-library or configuration gap rather than a mismatch — there is nothing to compare. AADSTS700016 - UnauthorizedClient_DoesNotMatchRequest - The application wasn't found in the directory/tenant. fails earlier still: the client ID or the tenant in the authorize URL is wrong, or the app was never consented to in that tenant, so Entra never reaches the redirect-URI check. If you see 700016, fix the client ID and tenant before you look at a single URI.

Next time a sign-in dies on the last hop, walk these checks back in order: what URI did the request carry, which platform list should hold it, does diff agree the two strings are identical, and only then edit the registration.