Azure Active Directory (Azure AD)

How to fix AADSTS50011: The reply address does not match the reply addresses configured… error

This post was most recently updated on November 23rd, 2018.

So, you got an error with a code AADSTS50011? That’s ok – it’s just Azure AD’s authentication acting up because of invalid reply URLs! Since there might be a couple of different reasons for this error, this post also describes a couple of different solutions, that might help you overcome the issues.


So, you’re getting an error somewhat like this:

AADSTS50011: The reply address ... does not match the reply addresses configured for the application.
AADSTS50011: The reply address … does not match the reply addresses configured for the application.

But why? Did you mess something up? Well, if you’re the person who configured the app you’re trying to use, you probably did! Although Microsoft might still be the one to blame for that.

Reason for getting AADSTS50011

Most typical error I’ve seen, would be “AADSTS50011: The reply address does not match the reply addresses configured for the application.”

Another variation of this error is “AADSTS50011: the reply url specified in the request does not match the reply urls configured for the application…”

This error can typically be caused by 2 different configuration issues. You’re either (1) accessing the page from a different address than what you’ve configured for your app, or (2) you have made a mistake in the configuration itself. In both of these cases, it’s typically fairly easy to fix the issue. You’ll probably want to just tweak the configuration – let’s see how!

Oh – and in case you’re an end-user, with no access to Azure AD configuration (either the 1.0 endpoint at or 2.0 endpoint at, and you’re getting this issue, you’re going to have to contact whoever in your organization handles this kind of stuff.

However, if you can edit these permissions yourself, see a couple of things you could check below!

Solution(s) to different “The reply address does not match the reply addresses configured” -errors

These instructions and screenshots apply to Azure AD v2.0 endpoint – that’s the shiny, new and already kind-of-deprecated endpoint, that a lot of new apps are using.

It supports personal accounts (and not just organizational ones), requires just one App Id for multiple platforms, supports dynamic permissions and much more. See the full list of the perks here!

Microsoft is moving away from it, though. And I’m not complaining – the GUI for app registration made it easy to make mistakes. The new “App Registrations (Preview)” in Azure Portal will likely eventually replace the site. See more here:

However, pretty much everything applies to v1.0 endpoint, too – just find the registration under Azure Portal > Azure AD -> app registrations.

Anyway, about the fixes – I’ve got a few solutions you could try.

The simple solution: Make sure, that your URL is actually included in the configuration

This might be obvious, I admit, but worth mentioning. So, this is what to do:

  1. Browse to
  2. Log in using the account that the app was registered with
  3. Click on your app
  4. Check the “Redirect URLs” -section and verify, that the URL you’re accessing the app from really is listed there!
"Redirect URLs" in
“Redirect URLs” in

What if you now have this error code, but with error description “Reply address did not match because of case sensitivity.”?

I have started encountering this lately – it seems, that Microsoft has implemented a bit more detailed error messages as of late. I’m not the one to complain about that! Check this article out: How to fix AADSTS50011: Reply address did not match because of case sensitivity.

What if you already added the URL, but it’s still not working?

A couple of things to check:

  1. Is the app id (client id) the same? You’ll need to verify, that you’re actually working on the same app that you’re using on whatever page that throws the error.
  2. Check out this bug and the workaround:
    2. From the link:
      1. Go to
        in the upper-right corner
      2. Click the Try the preview button, that will take you to the new SharePoint admin center
      3. From the sidebar, click the API management link
      4. Opening this page should trigger provisioning the necessary configuration.

To be updated, when new gotchas are found! 🙂

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!