Increasing session timeout to a week or more - asp.net

Question

In order to increase session timeout, it appears I would use the following setting:
<system.web>
<sessionState mode="InProc" timeout="20" />
/* Etc... */
</system.web>
Here the timeout is set to 20 minutes (the default value). And, apparently, the maximum value is 525,600 minutes, or one year.
I can come back to Facebook a week later and I'm still logged in. This is how I want my application to behave. But according to this answer, this can adversely affect performance because "your inactive sessions will remain in Web server memory which may cause application pool to recycle, which would result in loosing all sessions for all users."
Does anyone know the details about this performance hit? And, if it's for real, is there a more performant way to keep users logged in like sites such as Facebook?
UPDATE:
Below is the relevant section of my current web.config file.
<system.web>
<authentication mode="None" />
<sessionState mode="InProc" timeout="60" />
<compilation debug="true" targetFramework="4.6" />
<httpRuntime targetFramework="4.5.2" executionTimeout="240" maxRequestLength="20480" />
<httpModules>
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" />
</httpModules>
<customErrors mode="Off"></customErrors>
</system.web>
<system.webServer>
<modules>
<remove name="FormsAuthentication" />
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" preCondition="managedHandler" />
</modules>
<validation validateIntegratedModeConfiguration="false" />
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="20971520" />
</requestFiltering>
</security>
</system.webServer>
UPDATE 2:
Looks like I was incorrectly conflating two issues (authentication and session state). I apologize for not correctly sorting through some issues I was Googling on. My goal is only to extended the length of time a user is logged in.

Answer 1

For Login, you must use FormsAuthentication or ASP.NET Identity (Improved version of cookie based authentication over FormsAuthentication) which allows you to keep authentication cookie for more then weeks/months. FormsAuthentication is stateless, and in order to support multiple servers, you can use single machineKey in all servers. All samples and tutorials mostly guide to use FormsAuthentication by default.
Faceboook and everyone use authentication cookie, no body uses Session for login.
Ideally Session is bad and mostly unnecessary. It can be replaced with HttpRuntime.Cache. Cache can be easily setup to use some external provider such as Fabric cache or Redis. To make cache isolated by user, you can simply append keys of cached item with username.
UPDATE
There is no downside in using FormsAuthentication except that there is little CPU overhead required in decrypting cookie, but that can also be avoided by caching authentication ticket.
The only reason to support Session could be compatibility with old ASP application they might be supporting.
In the new ASP.NET MVC sample, they have configured cookie based authentication in code (in startup), which is not session. Though session is configured in web.config but as long as you don't want to store anything in session, you can completely disable it.

Answer 2

Created a stock MVC project from scratch with Individual User Account selected for Auth.
Startup.Auth.cs
public partial class Startup {
// For more information on configuring authentication, please visit http://go.microsoft.com/fwlink/?LinkId=301864
public void ConfigureAuth(IAppBuilder app) {
// Configure the db context, user manager and signin manager to use a single instance per request
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);
// Enable the application to use a cookie to store information for the signed in user
// and to use a cookie to temporarily store information about a user logging in with a third party login provider
// Configure the sign in cookie
app.UseCookieAuthentication(new CookieAuthenticationOptions {
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider {
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
},
ExpireTimeSpan = TimeSpan.FromDays(7)//<-- I just added this.
});
//...code removed for brevity
}
}
// Summary:
// Controls how much time the cookie will remain valid from the point it is
// created. The expiration information is in the protected cookie ticket. Because
// of that an expired cookie will be ignored even if it is passed to the server
// after the browser should have purged it
public TimeSpan ExpireTimeSpan { get; set; }
Changed nothing else in the project and the default template provided everything needed.
UPDATE
Based on comments, you could always add it as a app setting in web.config and use ConfigurationManager to access it. That way it can be modified without having to recompile code.
var expireTimeSpan = TimeSpan.FromDays(7);//the default
var setting = ConfigurationManager.AppSettings["ApplicationCookieExpireTimeInDays"];
if (setting != null) {
var days = 0;
if (int.TryParse(setting, out days)) {
expireTimeSpan = TimeSpan.FromDays(days);
}
}
// Enable the application to use a cookie to store information for the signed in user
// and to use a cookie to temporarily store information about a user logging in with a third party login provider
// Configure the sign in cookie
app.UseCookieAuthentication(new CookieAuthenticationOptions {
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider {
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
},
ExpireTimeSpan = expireTimeSpan
});
Where web.config would hold the setting.
<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
<add key="ApplicationCookieExpireTimeInDays" value="14" />
</appSettings>

Answer 3

The answer you cite is partially true. It depends on where the session state is stored.
There should be no issue with increasing the session state when storing the session state in the SQL Server database. Also using Web Farms - which makes sense to cater for scalability.
From this article:
Storing Session State in a SQL Server Database
Storing session variables in the SQL server has the following
advantages:
Scalability: If you are looking for a highly scalable option to store
your session variables, the SQL Server option is for you. It is a much
more scalable option than the others. Web farm architecture can very
easily access the session variables because they are stores in an
independent database.
Reliability: Because the data is physically
persisted in a database, it is is more reliable than the other
options. It has the ability to survive server restarts.
Security:
SQL Server is more secure than the in-memory or state server option.
You can protect your data more easily by configuring SQL Server
security.
It's an old article, but these principles still apply.
There can be issues when using memory of the Web Server.
How does increasing the session timeout effect the application performance and why?
If you extend the duration of Sessions, any items held in session
variables will stay in memory on the server longer. Depending on how
busy your application is, and the type and number of items you
persisits as session variables, this may degrade performance.
copied in the typo from the quote.
This question also discusses the difference between session state and the use of cookies with FormsAuthentication.
Should I use Session State or FormAuthentication to keep track of a signed-in user?
So depending on what type of authentication you are using - you may go the cookie route, bearing in mind the user can delete the cookie from the browser and this will log them out.
This is another helpful link to the docs.
Securing Session State