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

SlidingExpiration in CookieAuthenticationMiddleware works, but perhaps not like the user or the dev would expect it

Jan 6, 2014 at 1:00 AM

I've noticed, that CookieAuthenticationMiddleware does not renew my Auth-Cookie when I navigate between the pages of my web-app, although I've configured SlidingExpiration. When you look into the sources, you find the below placed logic for re-issuing the cookie.

As I understand it, (t2 < t) means: After 50% of the cookie's living time, the cookie is re-issued, when the user makes an request and there is SlidingExpiration configured. I think, that might not be, what the users or the devs expect.

Lets say, there is a ExpireTimeSpan of 2 hours and SlidingExpiration=true:

Scenario 1

a) The User logs in at 10:00
b) The User uses the app again at 11:59
c) The User can use the app at 13:00
  • Everything is finde
But the following won't work:

Scenario 2

a) The User logs in at 10:00
b) The User uses the app again at 10:59
c) The User can't use the app at 12:00 ALTHOUGH the timespan between b) and c) was the same, as in the last scenario

What do you think about this?
Is the current implementation "by design" and do I miss an aspect?


if (issuedUtc.HasValue && expiresUtc.HasValue && base.Options.SlidingExpiration)
TimeSpan t = utcNow.Subtract(issuedUtc.Value);
TimeSpan t2 = expiresUtc.Value.Subtract(utcNow);
if (t2 < t) {
    this._shouldRenew = true;
Jan 6, 2014 at 8:59 PM
Yep, your analysis is correct. The sliding expiration feature is modeled direcly on the the implementation of the ASP.NET "Forms" http module.

The question to ask is: does the time span represent the longest possible cookie duration, or the longest possible gap between visits?

In the owin middleware, and forms http module, the time span represents the longest possible cookie duration, and the longest possible gap between visits is 50% of that value. If in your example you wanted a 2h gap between visits, you would set the cookie expiration to 4h.

On the other hand, to make the values equal, you would need to re-issue the cookie on each request. The overhead of that isn't the end of the world, but for most cases it isn't necessary and most people don't expect to have a set-cookie with a new value returned form every response.

That said, if you add a filter to your web app that does a "sign-in" on every single authenticated request, which would re-issue the cookie in every response. At that point you could let the sliding expiration remain false.
Marked as answer by manfredsteyer on 1/6/2014 at 1:41 PM
Jan 6, 2014 at 9:40 PM

thanks for your answer. It's funny, that I've used the "forms" http module with sliding expiration since it's first days and neither I nor my customers have noticed this. So perhaps, this is just a theoretical issue, that doesn't matter in practice.

Perhaps "longest possible gap" isn't the best way to put it, cause depending on the scenario, there can be longer gaps too. But, perhaps, one could say, that if the TimeSpan is 2 hours, the user has to access the site every (2 x 50% = 1) hour.

The idea with the filter is great. Thank you for that.