SSOGEN / Free tools / AADSTS50011: Find the Redirect URI Mismatch With a Free Checker

Free tool

AADSTS50011: Find the Redirect URI Mismatch With a Free Checker

AADSTS50011 means the redirect URI your app sent does not match any redirect URI registered for it in Microsoft Entra ID. Paste the request and the registered list into this free checker and it marks the exact part that differs, in your browser.

Plan a trial

Compare the request with the registered list

Paste the sign-in URL in box A and the registered redirect URIs in box B, one per line, then select Check.

A. The authorization request URL, the redirect_uri value, or the error text

Paste the full URL from the browser address bar when the error appears, or only the redirect_uri value, or the text of the error message that says "The redirect URI ... specified in the request".

B. The redirect URIs registered for the application, one per line

Copy them from the app registration screen of your identity provider.

Provider rules

Private by design. The check happens in this page and nothing is sent anywhere. A sign-in URL can hold an application ID, a state value and a code challenge: use a copy you are allowed to look at, and never paste a URL that already carries an authorization code or a token.

Press Check to compare the two. Nothing runs until you do.

Free, in your browser. No sign-up and no limit. The page makes no network request when you check and never reads your Entra tenant. It compares only the text you paste.

The result is match or no match. The tool shows the closest registered entry with the differing characters marked, states the first difference in words and lists the fix steps.

In box A, paste the sign-in URL from the browser’s address bar when the error appears. The tool extracts the redirect_uri parameter and decodes it once, as the server does. The bare redirect URI value or the error text also works.
In box B, paste the app’s registered redirect URIs, one per line.
Select Check.

To get the exact reply address your app sent, capture the sign-in and open it in the HAR file analyzer. The Acme samples (acme.example is a reserved example domain) show the five most common mismatches.

A sign-in URL can contain an application ID and a state value. Paste a copy you are allowed to share, and never one that already carries a code or a token.

The Provider rules selector sets which rules the tool applies:

Microsoft Entra ID applies the restrictions Microsoft documents and labels each one “Microsoft Entra rule”.
Generic OAuth/OIDC applies the standards: exact string comparison, with a variable port allowed only for loopback redirects of native apps.

The tool does not guess at any other provider’s behavior.

What AADSTS50011 means

AADSTS50011 is what Microsoft Entra ID returns when the redirect URI (also called the reply URL) in a sign-in request is not on the list registered for the app.

Entra ID compares the two values as strings, so any difference fails the match. The fix is nearly always to make them identical. The checker above shows which part differs.

Scheme. A different scheme fails the match.
Host. A different host fails the match.
Port. A different port fails the match.
Path. A different path fails the match.
Trailing slash. A slash on one side only fails the match.
Letter case. A different letter case fails the match.

What the error says

Microsoft’s troubleshooting page gives the message as:

“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.”

Two values in it matter:

Redirect URI. The value the app sent.
Application (client) ID. The registration Entra ID checked the value against.

Microsoft Learn (read 2026-10-09) describes the check:

The app sends the user to Entra ID with a redirect URI.
After the user is authorized, Entra ID compares that value with the redirect URIs on the registered application.
If none matches, Entra ID returns AADSTS50011. If one matches, it sends the user there.

Microsoft gives the reason: the sign-in server only redirects users, and sends tokens, to redirect URIs added to an app registration.

Causes, ranked

This order is our judgment of how redirect URIs usually go wrong, not a count from Microsoft. Work down the list.

Rank	Cause	How to check it
1	The app was moved to a new address (new environment, new domain, new path) and the registration was not updated	Compare the host and path in the error with the registered list. The checker names the part.
2	The app sends `http` where `https` is registered	Read the scheme in the error. An app behind a TLS-terminating proxy or load balancer often builds its address from the request it sees, which is plain http.
3	A different path than the one registered	Compare the path character by character. Frameworks have default callback paths, and a library upgrade can change one.
4	Letter case differs	Microsoft says redirect URIs are case-sensitive and must match the case of the URL path of your running application.
5	A trailing slash on one side only	Look at the last character of both.
6	A port is present on one side only, or differs	Microsoft says the port is not ignored when matching, except for localhost.
7	The registration is on the wrong app, or on a different tenant	Compare the application ID in the error with the registration you edited.
8	The URI was added to the service principal and not the app registration	Microsoft says to add redirect URIs to the application object only, because values added to a service principal can be removed when the two objects sync.
9	A change was saved a moment ago	Microsoft says to wait three to five minutes after saving.

Mismatch types and fixes

Type	Request	Registered	Fix
Scheme	`http://app.acme.example/signin-oidc`	`https://app.acme.example/signin-oidc`	Make the app send https. Microsoft says http is supported only for localhost URIs.
Trailing slash	`https://app.acme.example/signin-oidc/`	`https://app.acme.example/signin-oidc`	Register, or send, the same form.
Path	`.../signin-oidc`	`.../signin-callback`	Register the path the app uses, or change the app’s callback path.
Port	`https://app.acme.example:8080/signin-oidc`	`https://app.acme.example/signin-oidc`	Register the port the app really uses.
Letter case	`.../SignIn-OIDC`	`.../signin-oidc`	Copy the exact case.
Host	`www.acme.example` against `acme.example`	one of them	Register each host that the app can send, as separate entries.
Localhost port	`http://localhost:5001/cb`	`http://localhost/cb`	No fix needed: Microsoft says the port is ignored for localhost matching.
Query string	`...?tenant=a`	none	Microsoft allows query parameters in redirect URIs only for apps that sign in work or school accounts only.
Wildcard	any	`https://*.acme.example/cb`	Microsoft says wildcards are unsupported when personal Microsoft accounts are included, and allowed (through the manifest editor) for work or school accounts only. The checker does not evaluate them.
Encoded twice	`https%253A%252F%252F...`	any	Encode the `redirect_uri` value once when you build the request.

The tool flags a host that differs only in letter case as a mismatch. Microsoft states the case rule with a path example and gives no separate host rule, so the tool takes the cautious reading.

Fix it in the portal

These are the steps on Microsoft’s troubleshooting page (read 2026-10-09):

Copy the application ID from the error message.
Sign in to the Azure portal with an account that may update app registrations.
Go to Microsoft Entra ID, select App registrations, find the registration by the application ID and open it.
Select Authentication. In the section that lists the redirect URIs by app type, select Add URI and enter the redirect URI exactly as the app sends it.
Save, wait three to five minutes, and send the sign-in request again.

Add the URI under your app type. In Microsoft’s tables:

a traditional web app is Web;
a single-page application is Single-page application (SPA);
a native app is Mobile and desktop applications.
Wrong value sent. If the value the app sent is the wrong one, Microsoft says to change the app’s code or configuration instead of the registration.
Sign-in page missing. If the sign-in page does not appear after the change, Microsoft suggests clearing the browser cache or using an InPrivate window.

Check the limits before you add entries:

A registration holds at most 256 redirect URIs for work or school accounts only, and 100 when personal accounts are included.
Each URI can be at most 256 characters.
Per Microsoft, redirect URIs do not support the characters ! $ ' ( ) , ; or internationalized domain names.

Localhost and development

Microsoft documents two special cases for loopback redirects, citing RFC 8252:

Plain http is allowed for localhost.
The port is ignored when matching a localhost redirect URI, so http://localhost:1234/MyApp and http://localhost:8080/MyApp are equivalent.

This applies only to localhost. Everywhere else the port counts.

Microsoft adds three cautions:

Do not register several localhost URIs that differ only by port, because the sign-in server picks one arbitrarily. Distinguish them by path.
The IPv6 loopback [::1] is not currently supported.
Use 127.0.0.1 rather than localhost. The portal’s Redirect URIs box does not accept an http loopback URI in that form, so set it in the application manifest.

The same error in other OAuth and OIDC providers

Each provider words this error differently, and this page does not cover any one provider’s screens or messages. The standards give the common rule:

RFC 9700, section 2.1 says servers must use exact string matching, except for the port in localhost redirection URIs of native apps.
RFC 6749 (section 3.1.2.3) asks for simple string comparison against the registered URI.
RFC 8252 gives native apps two more options: a loopback address with a port chosen at run time (section 7.3), or a custom scheme built from a domain you control, in reverse order (section 7.1).

Situation	What the standards say
Web app, full URI registered	Exact string comparison (RFC 6749 3.1.2.3, RFC 9700 2.1)
Pattern or wildcard registered	RFC 9700 section 4.1 describes patterns as a source of attacks. Servers should not rely on them.
Native app, loopback	The port may vary at run time (RFC 8252 7.3, RFC 9700 2.1)
Native app, `localhost` name	RFC 8252 section 8.3 says this is not recommended; use the IP literal
Native app, custom scheme	Reverse domain name of a domain you control (RFC 8252 7.1)
URI with a fragment	Not allowed in a redirection endpoint (RFC 6749 3.1.2)
URI fails validation	The server must not redirect to it automatically (RFC 6749 4.1.2.1)

The last row explains the symptom. The server does not send the browser to an unregistered address.

The error therefore appears on the identity provider’s own page, and the app never receives a response.

Why exact matching exists

The redirect URI is where the server sends the authorization code or token. If an attacker can make the server send it to an address the attacker controls, the code is theirs.

RFC 9700 section 4.1 describes two attacks that exact matching stops:

Pattern matching. Some servers let clients register patterns instead of full URIs. An attacker can then craft a URI that fits a too-broad pattern. Its example: a pattern like https://*.somesite.example/* might accept https://attacker.example/.somesite.example under a naive reading.
Open redirector. An open redirector on the client forwards the browser to an attacker’s address, and a token in a fragment goes along.

The mismatch error means the check is working. Fix one of the two strings; do not loosen the check.

PKCE adds a second defense by tying a stolen code to the app that requested it. It does not replace a correct redirect URI.

For the background, read what OAuth 2.0 is and what OpenID Connect is.

Inspect the token. Once sign-in works, inspect the returned token with the JWT decoder.
Connect Entra ID to SSOGEN. See Microsoft Entra ID SSO with SSOGEN.
Same rule in SSOGEN. SSOGEN applies the same rule to its own OpenID Connect applications: redirect URIs match character for character, with no wildcards, and each one starts with https://.

What does AADSTS50011 mean?

The redirect URI (reply URL) in the sign-in request does not match any redirect URI registered for the application in Microsoft Entra ID, so Entra ID will not send the person or the tokens there.

How do I fix AADSTS50011?

Copy the redirect URI from the error, open the app registration named by the application ID, go to Authentication, add that URI under the right app type, save, and wait three to five minutes. If the URI in the error is not the one you intended, fix the app’s configuration instead.

Is a redirect URI case-sensitive?

In Microsoft Entra ID, yes. Microsoft says redirect URIs are case-sensitive and must match the case of the URL path of the running application. RFC 6749 asks for simple string comparison.

Does the port matter in a redirect URI?

Yes, except for localhost. Microsoft says the port is ignored when matching a localhost redirect URI, and is not ignored in any other case.

Can I use a wildcard in a redirect URI?

Microsoft allows wildcards only for apps that sign in work or school accounts of one organization, added through the manifest editor, and recommends against them. RFC 9700 requires exact string matching for servers that follow it.

What is the difference between AADSTS50011 and AADSTS50020?

AADSTS50011 is about the address: the redirect URI sent does not match the app’s registration. AADSTS50020 is about the person: Microsoft’s error list says the user’s account from the identity provider does not exist in the tenant, so it must be added as an external user or invited through B2B (read 2026-10-09).

What does InvalidReplyTo mean?

It is the name Microsoft’s error-code list gives AADSTS50011 (read 2026-10-09). The reply address is missing, misconfigured or does not match the reply addresses configured for the app, and the fix is to add the missing address to the Microsoft Entra application.

Is it safe to paste my sign-in URL here?

The check runs in your browser and sends nothing. The URL may hold an application ID and a state value, so use only what you may look at, and do not paste one that carries an authorization code or token.

If your sign-in fails with a different code, the same error reader on these pages covers these errors.

AADSTS50020. The account is not in the tenant.
AADSTS50105. The user is not assigned to the app.
AADSTS90072. An external account cannot satisfy the tenant’s MFA.
AADSTS700016. The application is not found in the directory.

Sources

Sources, all read 2026-10-09: Microsoft Learn, Error AADSTS50011 and Redirect URI (reply URL) best practices and limitations; RFC 9700, sections 2.1 and 4.1. Also named in the text, without links: Microsoft’s error-code list (Microsoft Entra authentication and authorization error codes, read 2026-10-09), RFC 6749 sections 3.1.2, 3.1.2.3 and 4.1.2.1, and RFC 8252 sections 7.1, 7.3 and 8.3. See the other free tools. Microsoft and Entra are trademarks of their owner; SSOGEN is not affiliated with Microsoft.