Suppose I use something like this in the web.config
<authentication mode="Forms">
<forms
loginUrl ="~/HomeLogin.aspx"
cookieless= "AutoDetect"
slidingExpiration="true"
timeout="10"
protection ="All"
/>
</authentication>
If slidingExpiration is set to true (the default), each time the FormsAuthenticationModule authenticates a user, it updates the ticket’s expiry. If set to false, the expiry is not updated on each request, thereby causing the ticket to expire exactly timeout number of minutes past when the ticket was first created.
Note:
The expiry stored in the authentication ticket is an absolute date and time value, like August 2, 2008 11:34 AM. Moreover, the date and time are relative to the web server’s local time. This design decision can have some interesting side effects around Daylight Saving Time (DST), which is when clocks in the United States are moved ahead one hour (assuming the web server is hosted in a locale where Daylight Saving Time is observed). Consider what would happen for an ASP.NET website with a 30 minute expiry near the time that DST begins (which is at 2:00 AM). Imagine a visitor signs on to the site on March 11, 2008 at 1:55 AM. This would generate a forms authentication ticket that expires at March 11, 2008 at 2:25 AM (30 minutes in the future). However, once 2:00 AM rolls around, the clock jumps to 3:00 AM because of DST. When the user loads a new page six minutes after signing in (at 3:01 AM), the FormsAuthenticationModule notes that the ticket has expired and redirects the user to the login page.
This is an instance where it might cause issues.Can anybody point out any such downside to this approach.I am interested in knowing about it.
Thanks
FormsAuthentication uses UTC time for calculations. You would need to go to the source code (or Reflector) to see this, all the properties/methods working with UTC-dates are internal.
Cookies use UTC time for the expires date according to RFC 6265, section 5.1.1.
This means that DST won’t be a problem.
Sliding expiration will allow a login for indefinite time as long as the user is active. This means that a third party could grab the cookie enroute and authenticate as the user for an equally indefinite time.
An absolute expiration would not stop this, but would require re-authentication at regular intervals, limiting the time window the third party can use the cookie.