Authentication cookie not always set properly

Jan 21, 2015 at 6:57 AM
Hi, we're using the latest nuget releases of Owin middleware (3.0.0) in an MVC 5 app and the authentication is using Open ID Connect & Azure AD. At times the site sign-in starts working, here's how it works:
1) User opens web site
2) User clicks sign-in, get's redirected to Azure AD
3) User logs in at Azure AD - or existing session is recognized, redirected back to our site
4) User is back at our web site, with Request.IsAuthenticated == false in the view.

Weirdly enough, the issue always gets resolved by restarting the website. I have seen this issue somehow more often lately but that might be due to larger amount of users and/or just chance.

The authentication is configured like this: https://gist.github.com/htuomola/f549fac719563b04ca00.

I got Fiddler traces of the failed authentication flow and it looks like the following:
A) Auth flow is triggered by going to /Account/SignIn, Server responds with 302 redirect to Azure and sets OpenIdConnect.nonce.OpenIdConnect cookie
B) Azure login - existing session is recognized and it does form submit back to site root with code, id_token, state and session_state values
C) POST response gets 302 reply but no cookie is set on the response

The raw response in step C is simply:
HTTP/1.1 302 Found
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 0
Expires: -1
Location: /
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Wed, 21 Jan 2015 06:50:47 GMT
Any ideas what might be wrong here? Or how can I get some understanding on how this happens? I did configure Owin logging with the following but there are not many lines in the log file:
    <sources>
      <source name="Microsoft.Owin">
        <listeners>
          <add name="KatanaListener" />
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add name="KatanaListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="app_data\logs\Katana.trace.log" traceOutputOptions="ProcessId, DateTime" />
    </sharedListeners>
    <switches>
      <add name="Microsoft.Owin" value="Verbose" />
    </switches>
The only entries I see are:
Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthenticationMiddleware Warning: 0 : The nonce cookie was not found.
Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthenticationMiddleware Error: 0 : Exception occurred while processing message: 'System.Runtime.ExceptionServices.ExceptionDispatchInfo

Can this error be the reason the authentication fails? I guess it comes from OpenidConnectAuthenticationHandler.cs

Ok, by the time I got writing up to here and reading the code, I figured I should register AuthenticationFailed notification handler to get a grasp of the exception itself. I'll post this anyway in case anyone can shed some light on the real problem. Btw. at the very least there's this line in the OpenidConnectAuthenticationHandler:
 _logger.WriteError("Exception occurred while processing message: '" + authFailedEx.ToString());
authFailedEx is of type ExceptionDispatchInfo and it's ToString method apparently isn't too helpful. Maybe this validates a PR :).
Jan 21, 2015 at 7:13 AM
Now that I think of it, this error might be because of nonce mismatch errors that the user might end up if they try to directly access a protected page without being signed in. In those cases they get into a redirect loop at "ProtectedPage -> SignIn -> Azure AD -> ProtectedPage -> SignIn" and so on. Then if user detects this and hits browser stop button and refresh, they end up with a nonce error "OpenIdConnectProtocolInvalidNonceException: IDX10301: The 'nonce' found in the jwt token did not match the expected nonce."

But when just clicking "sign in" on the landing page, there's no error shown, even if user authentication didn't complete successfully and I hadn't registered AuthenticationFailed notification handler either.
Coordinator
Jan 21, 2015 at 5:09 PM
This may be related to https://katanaproject.codeplex.com/workitem/197
I say that because the response headers above look like all the headers normally set by the cookie auth middleware (Expires, Cache-Control, etc.), only the Set-Cookie header is missing. There are a few issues in System.Web where the Set-Cookie header may be removed or overwritten. Try the workarounds on that thread and let us know.
Marked as answer by htuomola on 2/4/2015 at 12:26 AM
Feb 4, 2015 at 6:53 AM
Hi, thanks for the response and excuse for my delay in replying. I wanted to give it a try first to see if it works. I turned off sessions (refactored out minor TempData usage) and we haven't seen the problem since. As we can do without sessions I didn't pursue the other workarounds presented in there, like custom CookieManager.