I’ve been educating myself on the capabilities of OpenID Connect/OAuth in Server 2016. The version I’m currently playing with is based on TP5. I created a small application which consists of a web application and an API. Just for educational purposes. The actual application can be found here: https://github.com/tvuylsteke/TodoListWeb
When I started testing my application I ran into an issue. I would visit my application, hit the sign in button and be redirected to AD FS. I would either enter my credentials or be authenticated transparently and then be redirected to my application. That’s where things went wrong. I always seemed to get this error:
In Words:We're having trouble signing you in.
IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.;
Some online searching led me to some threads but no real good suggestions. I also found a session off Build 2015: Cloud Authentication Troubleshooting and Recipes for Developers They mention that IDX10311 typically happens when you don’t receive an expected cookie from the browser. Likely cause: Your reply URL is sending the browser to somewhere different than where you started. I double checked everything, but that didn’t seem to be the cause.
Now I found out that using chrome everything was working as expected. Still I had no real clue. I posted my issue to an internal DL and one of my colleagues quickly spotted my issue using the Fiddler traces I provided. He told me that the OpenIdConnect.nonce.OpenIdConnect cookie was not being set correctly for the todolistweb.contoso.com application in IE. And when I took my traces I could indeed see this:
A trace from Internet Explorer:
You can see the response from AD FS and then the browser going back to the application without any cookies:
Now if we compare that to a session from within Chrome:
You can clearly see the OpenIDConnect.nonce cookie
As a solution to this issue I added my application to the Local Intranet Zone in IE and that resulted in the cookie being sent to the application. Mystery solved!