In a previous post I talked about an infinite redirect loop issue between an MVC application and Azure AD when performing sign in. In this post, we will look at another scenario which can lead to the same type of problem.


Applications running an old version of OWIN middleware can run into this issue because of a known Katana bug. Due to a cookie mismanagement issue in the old version of OWIN, an application is not able to recognize an authenticated request from Azure AD so it keeps sending the request back to Azure AD for login leading to the infinite loop issue.

Error Message

Customer may see this error message in the browser:  “We couldn’t sign you in.  Please try again.”

How to recognize the Katana bug…

Capture a Fiddler trace and examine one of the later redirect frames back to the web application. Note in the screen shot below, the request in frame 58 contains multiple OpenIdConnect nonce cookies (red-circled). In a working scenario, we should only have one OpenIdConnect nonce cookie set at the beginning before authentication. After the request is successfully authenticated, this nonce cookie is destroyed and sets its own session cookie. Because of this bug, we see there is a build up of these nonce cookies.

Resolving the issue…

The problem has been fixed in ASP.NET core and in the new version of Katana Owin for ASP.NET.  To resolve this issue, you can upgrade your application to use ASP.NET Core. If you must continue stay on ASP.NET, perform the following:

  1. Update your application’s Microsoft.Owin.Host.SystemWeb package be at least version and
  2. Modify your code to use one of the new cookie manager classes, for example something like the following:
app.UseCookieAuthentication(new CookieAuthenticationOptions 
    AuthenticationType = "Cookies", 
    CookieManager = new Microsoft.Owin.Host.SystemWeb.SystemWebChunkingCookieManager() 


app.UseCookieAuthentication(new CookieAuthenticationOptions() 
    CookieManager = new SystemWebCookieManager() 



0 0 vote
Article Rating
Notify of
1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
Rich Posada
Rich Posada
May 10, 2020 5:50 pm

If you are using Visual Studio, go to the properties page for you project. Click on the “Web” tab on left, view the settings in the “Servers” section and be sure that the Project URL is referencing the HTTPS URL and not the HTTP URL. This is causing the cookie collision in this scenario.