Last Updated: August 23 2019

Let’s get started…

When your developing or integrating an application with Azure AD, you might see the following similar error…


AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: ‘XXX’.


This is because the redirect_uri (when using OpenID Connect) or AssertionConsumerServiceUrl (when using SAML2) being passed to Azure Active Directory to sign-in, does not exist in the application registration.


For example, if using OpenID Connect, your authentication request might look something like this…

https://login.microsoftonline.com/common/oauth2/authorize?response_type=code
&client_id=99f00653-5600-45d1-aa19-57a297ad0a58&redirect_uri=https://www.contoso.com/signin-oidc

If you are signing in using a browser, you can also see this sign-in request in the browsers address bar on the error screen.

So, we are going to check if https://www.contoso.com/signin-oidc is a reply address in the application registration for 99f00653-5600-45d1-aa19-57a297ad0a58

We got the error because https://www.contoso.com/signin-oidc is not added as a reply address in the application registration.


For SAML authentication, The sign-in request might look something like this…

https://login.microsoftonline.com/common/saml2?SAMLRequest=jZHNS8NAEMXvgv9D2Hu...

The SAMLRequest is going to look like a long value of random characters. We call this a Base64 encoded string that is SAML enflated. So to ‘deflate’ this in order to read the contents of the SAMLRequest, you can use the TextWizard in Fiddler or use a tool like the one below…
https://www.samltool.com/decode.php

Once the SAMLRequest is deflated, it will look something like this…

<samlp:AuthnRequest
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="id6c1c178c166d486687be4aaf5e482730"
Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://www.contoso.com">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.contoso.com</Issuer>
<NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
</samlp:AuthnRequest>

The Assertion Consumer Service (ACS) within the SAMLRequest resembles the reply address.

So, we are going to check if ‘https://www.contoso.com‘ is a reply address in the application registration for the application ‘https://www.contoso.com’ which is identified by the apps ‘Identifier (Entity ID)’ in Azure Active Directory.

So what’s the solution?

So, to resolve this, you guessed it, ensure the redirect URI or Assertion Consumer Service URL is added to the application registration.

To do this…

  1. Sign into the Azure portal @ https://portal.azure.com
  2. Go to Azure Active Directory.
  3. Go to Application registrations.
  4. Find your app.
  5. Go to Authentication under Manage.
  6. Review your registered Redirect Uri(s).

How to determine what reply address is being used…

If you’re not sure how to collect this information, we generally like to use a HTTPS capturing tool like Fiddler (Available for Windows, macOS, and Linux).

To learn more about how you can use Fiddler, see the following article…

https://blogs.aaddevsup.xyz/2018/09/12/capture-https-traffic-with-http-fiddler/

You can look at the details of your request to Azure AD. Use the following article as a guide…
https://docs.telerik.com/fiddler/Observe-Traffic/Tasks/ViewSessionContent

7 Thoughts to “AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application”

  1. anand

    Hi,

    Thanks for the detailed post.

    even though i have registered the redirect url in the app in azure and added same url in the redirect uri in the oauth url, i was getting same exception while fetching authorization code.

    this is the exception log

    AADSTS500112: The reply address ‘http://testUrl’ does not match the reply address ‘https://testUrl’

    only difference i see in the above exception is the http and https.

    i don’t know how it came as http, because i have added both urls as https.

    i was using msal java library to integrate with azure

    1. Hey Anand, thanks for the comment. Based on the error message, it looks like your app/MSAL is sending the reply address with the non-https to Azure AD. Reply addresses must exactly match to whats in Azure AD including http vs https.

      https://github.com/AzureAD/microsoft-authentication-library-for-java/wiki/Acquiring-Tokens-with-Authorization-codes

      Following the article above, make sure you are passing the https reply address. If your using code to pull the sites host name, this sometimes might generate the http address instead of the https address.

  2. Sonu

    Hi I am still getting the error AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application:
     
    I have added the redirect URl to my localhost

    1. Thanks for your post. You have to add the redirect_uri that the app is sending us to the reply address list in the application registration. Easiest way to troubleshoot this is get a HTTP capture and figure out what that redirect_uri is, it might not be what you “think” it is. Once you have identified what that redirect_uri is, add it to the application registration. You also need to confirm you are updating the correct app registration so also verify the ClientId/AppId.

      If your still having problems. I would suggest engaging the Azure AD team in Microsoft Support.

  3. Monika Thakkar

    Hello,

    I am using this for mobile application and I am getting this error :AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the applicatio.

    Can you please suggest what should be redirect url for expo react-native mobile app?

    1. Bac Hoang [MSFT]

      You probably want to capture a Fiddler trace of your mobile app to see what redirect URL was used in the request and then configure that URL in the Application Registration portal

  4. Thanks for shedding light on this topic.NaN

Leave a Reply to Bill Fiddes [MSFT] Cancel reply