With cookieless forms authentication, if the browser is closed, the ticket is lost and a new ticket will be generated on the next request - https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.formsauthenticationconfiguration.cookieless?redirectedfrom=MSDN&view=netframework-4.8#System_Web_Configuration_FormsAuthenticationConfiguration_Cookieless
IsPersistent = true
if a durable cookie (a cookie that is saved across browser sessions) was issued; otherwise, false. - https://docs.microsoft.com/en-us/dotnet/api/system.web.security.formsauthenticationticket?redirectedfrom=MSDN&view=netframework-4.8
- There are two different types of cookies - session cookies and persistent cookies. If a cookie does not contain an expiration date, it is considered a session cookie. Session cookies are stored in memory and never written to disk. When the browser closes, the cookie is permanently lost from this point on. If the cookie contains an expiration date, it is considered a persistent cookie. On the date specified in the expiration, the cookie will be removed from the disk. - https://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/117925-technote-csc-00.html#:~:text=If%20a%20cookie%20does%20not,is%20considered%20a%20persistent%20cookie.
https://web.dev/samesite-cookies-explained/
Strict (http header) https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite#net-versions-earlier-than-472
SESSION STATE https://docs.microsoft.com/en-us/dotnet/api/system.web.sessionstate.httpsessionstate?view=netframework-4.8#remarks
- ASP.NET provides session-state management to enable you to store information associated with a unique browser session across multiple requests.
- Session data is associated with a specific browser session using a unique identifier. By default, this identifier is stored in a non-expiring session cookie in the browser
- Sessions are started during the first request and session values will persist as long as a new request is made by the browser before the number of minutes specified in the Timeout property pass
- Session state does not persist across ASP.NET application boundaries. If a browser navigates to another application, the session information is not available to the new application.
- Session values are stored in memory on the Web server, by default. [..]
SESSION ABADON https://docs.microsoft.com/en-us/dotnet/api/system.web.sessionstate.httpsessionstate.abandon?view=netframework-4.8#remarks
- Session identifiers for abandoned or expired sessions are recycled by default.
- That is, if a request is made that includes the session identifier for an expired or abandoned session, a new session is started using the same session identifier. You can disable this by setting regenerateExpiredSessionId attribute of the sessionState configuration element to true.
SESSION ID https://docs.microsoft.com/en-us/dotnet/api/system.web.sessionstate.httpsessionstate.sessionid?view=netframework-4.8#remarks
- The SessionID property is used to uniquely identify a browser with session data on the server. The SessionID value is randomly generated by ASP.NET and stored in a non-expiring session cookie in the browser. The SessionID value is then sent in a cookie with each request to the ASP.NET application.
- The SessionID is sent between the server and the browser in clear text, either in a cookie or in the URL. As a result, an unwanted source could gain access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing private or sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID.
- When using cookie-based session state, ASP.NET does not allocate storage for session data until the Session object is used. As a result, a new session ID is generated for each page request until the session object is accessed. If your application requires a static session ID for the entire session, you can either implement the Session_Start method in the application's Global.asax file and store data in the Session object to fix the session ID, or you can use code in another part of your application to explicitly store data in the Session object.