Cookie authentication tokens not properly being considered expired

Sep 8, 2014 at 7:02 PM
After upgrading to the 3.0.0 packages, I've been seeing an increase in errors related to cookie authentication, and after some debugging and looking through the katana code, I think I have an idea as what is going on.

For various legacy reasons, my project logs if an already authenticated user is having a new session created, via Global.ascx Session_Start(). After upgrading to 3.0.0, this has been happening far more often than it ever used to. Looking through my server logs, it seems to be happening to people using Chrome.

I added some additional debugging code that lets me log the IssuedUtc and ExpiresUtc values from the AuthenticationTicket, and every time I'm seeing the error, these values are null. Looking at the code, it seems that these would be null if the AuthenticationProperties was a freshly created instance and not one that was de-serialized from the cookie.

Did the serialization format of the AuthenticationProperties class change from 2.1.0 and 3.0.0?

The other thing I noticed in CookieAuthenticationHandler's AuthenticateCoreAsync() method, if expiresUtc or issuedUtc is null, it completely skips over the expiration check.

All of these things combine into my theory of what is happening. Chrome tends to define a browser session as lasting beyond a single browser process's lifetime, so per-session cookies stick around longer than you'd normally expect. A Chrome user of my site has an authentication cookies that was issued via 2.1.0 and then doesn't try to access my site until after I've made the change 3.0.0. The expiresUtc and issuedUtc values can no longer be parsed correctly, so they default to null. The AuthenticateCoreAsync() method is then considering this to be a valid token instead of expiring like it should, so my users are not getting prompted to log back in like my code is expecting them to.

Assuming I haven't missed something and my theory is correct, it seems like the more proper way to handle null expiration values would be to consider the token invalid instead of letting it through.

Of course, this is only a problem because of Chrome's "wonderful" definition of per-session cookie lifetime, but there doesn't seem to be a way around that.
Sep 9, 2014 at 1:07 AM
Here's the corresponding issue: