Troubleshooting common Azure Active Directory Errors

This is a list of common errors you might face when trying to integrate your application with Azure AD and the most likely causes for it. As you can see, in most cases the root causes are usually strings that don’t match. For a more detailed discussion, please watch my Build 15 presentation here:


Error: AADSTS50011: The reply address ‘https://someurlhere’ does not match the reply addresses configured for the application: c6827548-2019-4372-8ab8-44a7358be82c.



When you configure your AAD application on Azure, you have to set one or more reply URLs:



Now when your application attempts to authenticate against AAD, as part of that request it will provide the redirect URI it wants. This allows the application to know when the user’s authentication/authorization flow is finished so it can go ahead and take the access token. But… What if your application requests for a reply URL that is not in that list?

result = _authenticationContext.AcquireToken(resourceAppIdUri, clientId, “http://somethingelse”);

That URL is not in the list above, is it? So AAD is basically saying: “Hey, this doesn’t look ok. It could be someone else trying to pretend they are your app so I won’t go ahead.”. So to fix this you either include that URL in the list above, or fix it to one of the items in the list.


Error: AADSTS50011: Reply address ‘ms-app://s-1-15-2-5781234568-123456789-2012345674-91234567-212345678-1123456761-912345674/’ specified by the request is not a valid URL.



Now this is an interesting one. If you are a Windows Store app developer you have seen URIs like that before. They are URIs that point to your local app. And Azure AD doesn’t seem to like this one very much, it’s saying this is not a valid URL. And guess what? It isn’t indeed. Like the previous example, your Windows Store App is trying to authenticate and it’s providing this URI as the reply URI, which is something expected. But Azure AD seems to disagree with it. And the reason is actually quite simple:



When you create your application under Azure Active Directory, the first question is whether you are creating a Web App or a Native App. Well, if you choose Web App but later on you give this URL that has no HTTP or HTTPS in it, Azure will find that very odd and give you that error. In other words, if you are building a native app (whether that’s a Windows, iOS, Android, etc) then you need to create a Native Client Application under Azure AD so it will let you use this sort of URI.


Error: {“error”:”invalid_grant”,”error_description”:”AADSTS70002: Error validating credentials. AADSTS70000: The provided access grant is invalid or malformed…..



Ok, honestly? This is an awful error message. Really. It’s something we need to fix at Microsoft. But here’s what it really means in most cases:

When you configure your URL under the application settings in Azure AD, you forgot… a trailing slash! That’s it! Can you believe that?

In other words, change this:


to this:


Done! You’re welcome. 🙂


Error: {“error”:”invalid_resource”,”error_description”:”AADSTS50001: Resource ‘http://something/’ is not registered for the account



This is basically another “string doesn’t match” error. A “resource” is whatever you are trying to access. Each resource has an ID, we call it… well, resource id. So for example, if I want to access Exchange online from my app, I need to ask for an access token for that resource ID, which can be represented as a URL or a Guid in most cases.

So the error above is saying: You are asking access to something, but this something is not registered in the list of things your app is allowed to access.

Now the most common case for this error is simply that you registered that resource as “https://something/” but you are asking for “http://something/”. Yes, it matters. The string has to match perfectly or else it’s not the same thing. Another example is when you test your app in localhost, everything works but then you publish it and change the URL. Now it’s not localhost anymore. Port changes are another common cause. localhost:1234 is different than localhost:5678. So just make sure that the app id has exactly the same name as your code is asking for.


Error: {“error”:”invalid_resource”,”error_description”:”AADSTS50001: Resource identifier is not provided.



I see this error when folks craft their own OAuth 2.0 flows instead of using known, well-tested libraries. Otherwise you would usually get an error at compilation time or something else. This is telling that you are asking access to something but you didn’t tell what. Again the resource identifier is the thing you want to access. So your app goes to AAD and says:

“Hey, I’m the app <client ID> logging at the <authority> (which is usually<your tenant> and I want access to <resource identifier>”.

Most libraries, such as ADAL, will have that resource identifier as a parameter that you have to provide. But if you craft your http request manually you might miss it, and Azure AD will bump with that error.


Error: I see the login screen, I type my credentials but then I get a 404, page not found error. Why?



Well, remember the reply URL? That is the thing AAD will call after it’s happy with your login. If you put a URL there that doesn’t go anywhere, that’s where AAD will send your browser to. So what you want is to have a URL in the reply URL list that lands into some nice “welcome user blah!” page in your app. That page should exist, right?


Error: I see the login screen, I type my credentials but it never closes and my windows 8 app gets stuck. Why?



I will blame on the reply URL again (this bites a lot, doesn’t it?). Your windows 8 app launches the login screen which is basically a web browser loading a page from It can’t access the content of that browser for security reasons. All it can see is what URL that browser is at. And it is waiting to see a specific URL to load up so it knows the login is finished so it can close that browser. And that specific URL that “triggers” closing the login window is… guessed it? No? Yes, the reply URL. So if your code says you have a specific reply URL that doesn’t match what is actually happening on the server, this will happen.


Error: AADSTS50020: User account ‘’ from external identity provider ‘’ is not supported for application ‘2123456f-b123-4123-9123-4123456789e5’. The account needs to be added as an external user in the tenant. Please sign out and sign in again with an Azure Active Directory user account.



Scary, uh? Well, not really. First thing to know is that every object in AAD has an ID and that ID is a Guid. So that Guid number in “” means your tenant id. In other words, that’s a specific AAD directory for a specific organization that it’s talking about. And it is saying that user account is from an “external identity provider”. Well, so if belongs to that external identity provider so I can assume that Guid refers to the tenant where belongs. In other words, that Guid = It’s just another way of representing the same thing.

Now to the next part of the error: That user account is not supported for the application. Which application? Well, the one you are trying to logon to. So whatever client ID you used is the application this error is talking about.

So what does this error mean??

It means you have an Azure Active Directory tenant where your application is registered, and then another Azure Active Directory where this user you are trying to logon with is registered. And because these two tenants are different, Azure is blocking you. So likely causes are:

1-You have a cached user on your browser that is not the one you actually want to use for this test. Delete your cache or use IE’s “in private” mode so you can do your test

2-This is actually what you want. You want users from this other tenant to be able to logon and use the app from this separate tenant. This is very common in software as a service models. Company A builds an app and now companies B, C and D want to use it. So they want their users to logon to this app that exists only at the tenant of company A. What you need to do here is making this application “multi tenant”. It’s an actual setting under Azure Active Directory when you configure an application. This means you are telling Azure AD that users from other tenants can logon to this app, assuming their IT admins are ok with that. It’s a great model because it allows monetizing your app to other organizations. But unless you make it multi-tenant, users will get bumped with that error.


Error: IDX10205: Issuer validation failed. Issuer: ‘’. Did not match: validationParameters.ValidIssuer: ‘null’ or validationParameters.ValidIssuers: ‘{tenantid}/’.



Remember, when you see “” that Guid refers to a tenant ID.This error is basically saying that the tenant ID you gave to AAD is not the one it’s expecting to see. In other words, somewhere in the code you are saying: “”. Make sure your app is pointing to the tenant where everything was configured correctly and that you are not mixing tokens from one place to another.


Error: My OPTIONS request gets a 302 redirect to as a response!



So you have a JavaScript application making a CORS call to some web service hosted on Azure Websites. Your browser does a preflight, which means it calls that web service with an OPTIONS request instead of whatever your code is asking it to do. This is a security measure all modern browsers have. They are basically asking that server a simple question: “Hey server, I’m running here at this other site and this JavaScript told me to come talk to you and give you some sensitive information about this user. Are you expecting calls from this site or should I assume this is some hacker trying to steal information from my user and stop?”

Now the server should reply saying what it is actually expecting, which domains are allowed to call it, etc. But never, ever should that server reply to an OPTIONS request saying “I’m not talking to you until you authenticate”. Because an OPTIONS request is by definition anonymous. It provides no sensitive data exactly because this is the question it’s asking: “Should I provide you some sensitive data here?”.

The weird thing about this error is that if you try to debug it, you can’t. Your web service will do nothing. The error happens before your web service even can see that call. Why?


Azure websites have this awesome feature called easy auth. You go to your site and click at this configure button and you get authentication/authorization all set with zero code changes. Awesome, really. But… Once you do that, Azure will force all requests to that site to be authenticated. It doesn’t care where they come from. It doesn’t care if they are OPTIONS. It will just ask for authorization. In other words, this feature is not compatible with CORS so for that you have to disable this and configure your OAuth the traditional way, in your code.