AADSTS50011: Reply URL does not match

By Bram Brinkmeier · Checked against Microsoft documentation; lab test pending · Updated 2026-10-11

Short answer: AADSTS50011 means the redirect (reply) URI in the sign-in request doesn't exactly match one registered for the application. It is almost always a configuration mistake: http instead of https, a trailing slash, a wrong port. The exact-match rule is also what stops attackers redirecting authorization codes and tokens to their own server.

At a glance
Code	`AADSTS50011`
Microsoft name	`InvalidReplyTo`
Category	App configuration
Type	Failure
Attack signal	Low: usually configuration or user error
MITRE ATT&CK	T1528 Steal Application Access Token
Where to look	`SigninLogs`
Microsoft lookup	login.microsoftonline.com/error?code=50011

What does AADSTS50011 mean?

InvalidReplyTo: The reply address is missing, misconfigured, or doesn’t match reply addresses configured for the app. As a resolution ensures to add this missing reply address to the Microsoft Entra application or have someone with the permissions to manage your application in Microsoft Entra IF do this for you.

(The wording, including “IF”, is Microsoft’s.) The troubleshooting article shows the message users see:

The reply URL does not match the reply URLs configured for the application . Make sure the reply URL sent in the request matches one added to your application

For SAML apps, the article names the cause as the AssertionConsumerServiceURL in the request not matching the Reply URL configured on the app.

Is it an attack?

Almost always not. The common causes are small differences between what the app sends and what is registered:

http:// vs https://
a trailing slash, or a different path or port
a new environment (staging, a new hostname) that was never added to the app registration
a SAML app whose service provider sends a different ACS URL than the one configured

The security point is the control behind the error. Entra ID only sends an authorization code or token to a redirect URI the app owner registered. If that check were loose, an attacker could send a victim a sign-in link with their own server as the redirect and collect the code or token. 50011 is that check refusing.

Pattern	Likely meaning
Errors right after a deployment or hostname change	Missing reply URL. Benign.
One app, one wrong URI, many users	App misconfiguration. Benign, but users are blocked.
One app, many different redirect URIs, from one IP or a few users	Someone testing which redirect values the app accepts. Investigate.
50011 for an app ID you don’t recognise	Check whether the app is yours at all. See also 700016.

The probing pattern is our reasoning about how an attacker would look for a lax reply URL. Microsoft’s troubleshooting article doesn’t discuss security implications.

How do I find it in my logs (KQL)?

50011 per app per day, to spot misconfigurations after changes:

SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == "50011"
| summarize Users = dcount(UserPrincipalName),
            Attempts = count(),
            IPs = dcount(IPAddress)
          by AppDisplayName, AppId, bin(TimeGenerated, 1d)
| sort by TimeGenerated desc, Attempts desc

Few sources, many attempts against one app:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50011"
| summarize Attempts = count(),
            Apps = dcount(AppId),
            AppNames = make_set(AppDisplayName, 5),
            Users = make_set(UserPrincipalName, 5),
            UserAgents = make_set(UserAgent, 5)
          by IPAddress
| sort by Attempts desc

The sign-in logs don’t record the redirect URI that was sent, as far as the documented SigninLogs columns show. To see the exact value, use the error page or the request itself (browser developer tools, or the app’s own logs). Volume and source are what you can hunt on in the logs.

How does Conditional Access affect it?

50011 is not a Conditional Access result. The request fails on application configuration before a token can be issued.
Conditional Access doesn’t protect against a lax reply URL. If an app registration accepts a redirect URI you don’t control, a user who completes sign-in, MFA and device checks still sends the code to that URI. Review the registered reply URLs as part of app hygiene.

How do I fix AADSTS50011?

For the user: this isn’t something you can fix. Report the app name and the time to IT or the app owner.

For developers and admins:

Read the redirect URI from the failing request and compare it character for character with the app registration (Authentication for OIDC/OAuth apps, Basic SAML configuration > Reply URL for SAML apps).
Add the exact URI the app uses. Don’t add a broad or wildcard pattern to make the error go away.
Remove reply URLs for environments that no longer exist. A registered URI on a domain you let expire can be taken over and used to receive codes (reasoning, not a Microsoft statement).