Authentication cookie lifetime and sliding expiration in ASP.NET Core

[brokul-dev]

This issue contains comments displayed below the article:
https://brokul.dev/authentication-cookie-lifetime-and-sliding-expiration

[dannyAuburn]

Very nice job on the article.

[Gaurav-Puri101187]

Very Nice Article!!!

[mschaefer-gresham]

Thank you for this article. The article states that the cookie absolute lifetime is 3 days. But it looks like you are checking if it's older than 7 days:

 if (DateTimeOffset.UtcNow - ticketIssuedUtc > TimeSpan.FromDays(7))
        {
            await RejectPrincipalAsync(context);
            return;
        }

Am I missing something?

[brokul-dev]

Hi @mschaefer-gresham,
It should be TimeSpan.FromDays(3). I've fixed that. Thanks for pointing this out!

[mschaefer-gresham]

Hi @brokul-dev thank you.

Will the context property values be shared across mutliple instances of the server if you have configured a distributed cache, such as AddDistributedSqlServerCache?

context.Properties.SetString(TicketIssuedTicks, DateTimeOffset.UtcNow.Ticks.ToString());

Can you comment on the difference between storing TicketIssuedTicks in context.Properties versus context.HttpContext.Session? If I'm not mistaken values stored in context.HttpContext.Session will be persisted to the distributed cache. Could this be an alternative if the context.Properties are not cached?

[brokul-dev]

Hi @mschaefer-gresham, sorry for the late answer
When you use context.Properties, the TicketIssuedTicks is stored inside the authentication cookie in an encrypted form. If all app instances use the same "key ring" then it will be shared between them - these instances will decrypt data stored in a cookie:

• If you use "Azure App Service", it works out of the box - you can read more here: Data Protection key management and lifetime in ASP.NET Core | Microsoft Learn).
• If you use a different hosting solution, you might need to configure data encryption configuration, as described here: Share authentication cookies among ASP.NET apps | Microsoft Learn

In the case of a session, the data is stored in a separate session cookie. You might need to take care of its lifetime separately - deleting redundant data when the user logs out etc. However, that's not a big deal.

The solution you described will probably work when it comes to sharing sessions between instances. As described here: Session in ASP.NET Core | Microsoft Learn you can use any type of storage. If the SQL Server database is shared between app instances, then everything should be fine. But please verify that - to be honest, I don't have much experience with sessions in ASP.NET Core.

[SKullDugDev]

Wouldn't this be a performance drain as described here https://learn.microsoft.com/en-us/aspnet/core/security/authentication/cookie?view=aspnetcore-7.0 given that this would trigger on every request?

The included link warns that "The approach described here is triggered on every request. Validating authentication cookies for all users on every request can result in a large performance penalty for the app."

[shekarreddyb]

@SKullDugDev the link you provided is specifically talking about the code given in the page that makes a db call for validation (_userRepository.ValidateLastChanged(lastChanged))) not about CookieAuthenticationEvents.

[HOLz1919]

@brokul-dev is it possible to manually extend cookie authentication expiration?

[dpggit]

But why use CustomCookieAuthenticationEvents if can just set cookie max-age? in that way it will delete the cookie and wont last forever in case it is a hacker

[brokul-dev]

@dpggit The idea of this solution is to prevent extending cookie lifetime infinitely. The max-age allows setting the cookie expiration, but only on the user's browser side. In case a hacker captures a cookie like this, they could manually modify the expiration date and use it to access the backend on your behalf without any time limits.

[teneko]

Sorry to interrupt you, but is your logic not absolutely non-sense @brokul-dev when you say "authentication cookie could be potentially re-issued infinitely"? When trying to understand the cookie authentication code then the SlidingExpiration won't ever leading into extending the authentication token lifetime, more than specified by ExpirationTimeSpan ever. Example: If you specify ExpireTimeSpan = TimeSpan.FromMinutes(15) and you hit the SlidingExpiration at 8. minute, then according to this code line the diff of initial expiration datetime and initial issued datetime is added to the current time. So the expiration datetime should always be the same but the issue datetime should just be shifted. These new calculations expressed as new authentication token are then re-issued from the server via a new cookie. The value of the new cookie value is the encrypted authentication token. Am I wrong?

In the above assumptions I only consider the expiration datatime of the authentication token which is the encrypted value of the cookie, the date that is only considered by the CookieAuthenticationHandler. The cookie itself may have a cookie expiration time, so if CookieAuthenticationOptions.Cookie.Expiration is set, then this may only instruct the browser to delete the cookie on client-side, but would not mean automatically that the authentication token would be expired if you crafted your own ".AspNetCore.Cookies"-cookie with the authentication token as value. :D

To explain even further: You say "To prevent this situation, we should set absolute authentication cookie lifetime". But I want to try to tell you that the authentication token lifetime is actually absolute. If once expired, the cookie itself will be just ignored, so CookieAuthenticationEvents are never hit too.

And to underline, you are right, that the cookie expiration time should be actually renewed every time the cookie is getting re-issued, but never the authentication token expiration time. :)

[brokul-dev]

Hi @teneko
Try to set up the .NET app and register the cookie authentication scheme with settings like this:

options.ExpireTimeSpan = TimeSpan.FromMinutes(1);
options.SlidingExpiration = true;

Then log in to your app and keep refreshing the page every 10 seconds - just to be sure that you always hit the point where your ticket is more than halfway through its expiration window. Your authentication ticket will be automatically renewed every 30 seconds and if you keep refreshing the page you'll stay logged in forever. This is what I try to solve in this article.

[teneko]

This should not be possible. Have you inspected the corresponding code I have outlined? I have refreshed my page many times after the second half of expiration time and I was always logged out after after the absolute time specified by my ExpireTimeSpan. Have you another identity that is accidentally authenticated or missed protecting the endpoints with the correct authentication scheme, here cookie?

Edit: I will check it once again.