Compartilhar via


Invalid Client Secret when Publishing Azure AD Secured Apps

Back to my old nemesis…the long very long blog post title.  :-)   I ran across this problem myself recently, and had seen someone else experience but not had the time to dig into it.  In short the problem goes something like this – you create a new ASP.NET web application in Visual Studio 2015.  You configure it to be secured with Azure AD (i.e. Work and School accounts).  You do your thing, you build your web site, you test it locally, you can authenticate and everything works fine – great!

Now you want to deploy the app to your Azure web site.  You go through the publishing wizard, which pushes the content up to your web site.  It launches the browser for you to log in and check out your site but – boom – your app blows up.  After you authenticate it redirects you back to your site and you get the dreaded yellow page of death (i.e. an unhandled exception).  When you turn customErrors to Off in web.config you can see the error is “invalid client secret”.  You know it works fine when you run it on your local machine, so how can it be invalid?

This is the question that plagued me for a couple of days before I finally had the time to completely unwind it.  This post is partially “here’s how you fix it” and partially “this is why I think it happens”.  In the two cases where I’ve seen this happen so far, the project started out targeting .NET 4.52, then was subsequently changed to 4.61.  I noticed that the publishing wizard changes the UI slightly when you do that.

When targeting 4.52 the wizard includes a checkbox that says “Enable Organizational Accounts”.  The default behavior is to have that box checked.  I always uncheck it because my “organizational account” configuration is completed when I’m building and testing the application.  When targeting 4.61 I no longer see this option in the UI.

So here’s the fix and here’s the guess at what’s wrong.  If you look in the Properties folder in your project you will find one or more .pubxml files, which represent your publishing profiles.  In this case, the .pubxml file contained a completely different ClientId and ClientSecret value than my web.config did.  It was that client ID and secret that was getting pushed up to the Azure web site, and that’s why my application blew up once it was published to Azure.  To fix it, I just manually copied the ID and secret from my web.config into my .pubxml file.

Now…my guess as to why I think it happens (I deleted some stuff before I could actually verify this), I think when you have that box checked in the wizard when targeting 4.5.2, Visual Studio creates a new application definition in Azure AD, and then pulls in the client ID and secret from it into the publishing wizard.  That would explain how the wrong client ID and secret gets published and “stuff breaks”.

Anyways, if you run across this problem hopefully you’ll find this post.  Good luck!