Skip to content

Sliding and absolute expiration with cookie authentication middleware

November 18, 2014

The Katana cookie authentication middleware supports either a sliding or an absolute expiration, but not both. Recently a client was interested in having both, so I decided to figure out how this could be done.

It’s quite easy since the cookie authentication middleware allows for a Provider property where you can handle events for interesting activity in the middleware. The two events that I used were the OnResponseSignIn which is raised right before the outgoing cookie is issued, and OnValidateIdentity which is raised when the incoming cookie is being validated.

In OnResponseSignIn I add the absolute expiration to the issued cookie. I did not do this as a claim, but rather in the Properties of the cookie (which contains a dictionary for arbitrary values). Then in the OnValidateIdentity I simply read the value back from the dictionary in the Properties to check the expiration. To then cause the cookie to be ignored the RejectIdentity API is used. Since the cookie is dead, you can then optionally call SignOut to have the cookie revoked.

Here’s the code:

public void Configuration(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = "Cookie",
        ExpireTimeSpan = TimeSpan.FromHours(1),
        SlidingExpiration = true,
        Provider = new CookieAuthenticationProvider{
            OnResponseSignIn = ctx => {
                var ticks = ctx.Options.SystemClock.UtcNow.AddHours(10).UtcTicks;
                ctx.Properties.Dictionary.Add("absolute", ticks.ToString());
            },
            OnValidateIdentity = ctx =>
            {
                bool reject = true;
                string value;
                if (ctx.Properties.Dictionary.TryGetValue("absolute", out value))
                {
                    long ticks;
                    if (Int64.TryParse(value, out ticks))
                    {
                        reject = ctx.Options.SystemClock.UtcNow.UtcTicks > ticks;
                    }
                }

                if (reject)
                {
                    ctx.RejectIdentity();
                    // optionally clear cookie
                    //ctx.OwinContext.Authentication.SignOut(ctx.Options.AuthenticationType);
                }

                return Task.FromResult(0);
            }
        }
    });
}

HTH

8 Comments leave one →
  1. Andrey permalink
    January 23, 2015 11:59 am

    Great article and totally relevant to my work! Thanks for putting this knowledge into the Internet!
    Could this approach be extended to the use case when the sliding expiration for the authentication should be enabled, but some AJAX polling requests shouldn’t prolong the authentication session?
    With the old System.Web.Security.FormsAuthentication it was a pain. Does OWIN provide this flexibility?

    • January 26, 2015 6:05 pm

      Well, I’d argue that you should not be using cookies for authenticating your ajax calls. You should use tokens instead.

  2. Marcos Paulo Honorato da Silva permalink
    July 10, 2015 1:50 pm

    I have an MVC6 intranet application that uses roles. The admin users can manage all the user roles. However any changes made to a users’ roles are only effective when the user logs on (this makes sense as the roles are stored as claims in a cookie). The requirement is for role changes to take effect immediately, like they did in the older asp.net membership and role managers. How can one achieve this with the new identity models? The only way that comes to mind is to set some flag that is checked on each request and if set then update the cookie to reflect the new roles. Do you have any other suggestions or examples of how to ensure the role changes take effect immediatley?

  3. October 5, 2015 8:30 pm

    Hi Brock, why the properties of the cookie, and not the claims?

    • January 2, 2016 11:34 am

      Because it’s meta info about the authentication (and not about the user), and that’s what the properties are for.

  4. EasyDot permalink
    June 7, 2016 3:24 am

    Hi,

    Could you explain why we want both sliding and absolute expiration for our cookies? Is it for safety concerns? Isn’t the most secure option to have only the absolute expire time?

    Can the properties of the cookie be altered or are they also signed and encrypted by OWIN?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: