This project has moved and is read-only. For the latest updates, please go here.

Setting up to debug Katana + Azure Active Directory + OpenID Connect app locally using Azure emulator

Aug 31, 2014 at 8:55 PM
I spent several days trying to figure this out and thought others might be interested in the solution.

I've set up my web application in AAD, set a clientID, my sign-on url and my app id uri are assigned to http://localhost:58371/ (which AFAIK must be unique across my domain, so I can't my URLs in AAD to be 80 or 81 443 or 444 which could the emulator happier).
My RedirectUri and my PostLogOffRedirectUri in code are all pointing to the same localhost port.
And all that work great when I am running an instance of the web project. I can sign in and my cookie gets set, and it works great.

But when I started an instance of the cloud project, it runs in And since there isn't a way to set the ports on the emulator, I must run on the default ports in the emulator.
And the result is that when I log in, I get Server Error: Microsoft.IdentityModel.Protocols.OpenIdConnectProtocolException: OICE_20004: The 'nonce' was not found.

The fix is hinted at here:
You can add all of the URIs you need for your redirection in the Reply URI section of your Azure Active Directory application. I ended up with a list of them. I added three. One for my project to run in: http://localhost:58371/, another for the default port in the emulator, and another to my deployed web application:

I use the cscfg files to retrieve the particular setting that I need: <Setting name="RedirectUri" value="TheURIThatINeedForThatDeployment" /> in each .cscfg file.
I can retrieve the value using:
string redirect = CloudConfigurationManager.GetSetting("RedirectUri");
And then in Owin, I assign in the assign to OpenIdConnectAuthenticationOptions.RedirectUri.

Hope this save someone some time. :)
Sep 6, 2014 at 2:01 AM
I experimented with several solutions.

I ended up setting a separate Azure AD applications for each deployment (one locally, one for deploy) in the cscfg files.

This ended up to be clean, rather than trying to get AAD to figure out the replyUrl.