Best Practices: Session Management

Session management is the process of managing user sessions in a web application. A session is a series of interactions between users and a web application that take place over a period of time.

When sessions are well-managed, users can securely interact with the application and exchange sensitive information without having to frequently re-authenticate. The type of session management that organizations use depends on the sensitivity of the information being exchanged:

Short-lived sessions last as long as the user interacts with the application. Sessions end when the user signs out of the application or when the session lifetime limit is reached.
Long-lived sessions keep users signed on to the application even if they leave. These sessions store session IDs on user devices, which allows users to reopen an application and use it without needing to re-authenticate, and are most often used on mobile applications.

While long-lived sessions often provide users with a better experience, it can become a security risk if someone else obtains access to the device and the session is still active.

The challenge is finding the right balance between keeping application sessions safe and providing users with the best possible experience. If a session timeout is too short, it can frustrate users because they’ll be required to sign on again, but if it’s too long, sensitive information can be exposed that hackers can acquire. Failure to find this balance can either result in users abandoning their sessions and not returning to the application, or sessions being attacked, both of which can result in losing customers and revenue.

The specific challenges you might face depend on the type of application you’re protecting. For example, with workforce applications, because you understand who your users are and where they’re located, configuring application sessions might seem to be a simple task. However, when employees travel and occasionally work from different locations, session configuration becomes more complicated.

With retail applications, users are not always authenticated until purchases and other transactions occur, so it’s even more difficult to determine if a returning user is the same person. You can use long-lived cookies with unique values that identify specific visits and returns, but many users don’t want to be tracked and remove the cookies. Additionally, because other users might reside in locations where cookies aren’t allowed, relying on persistent cookies is not always possible.

Fortunately, there are a wide variety of ways to configure retail and workforce application sessions to ensure that authentication occurs at the appropriate time and place, using methods deemed appropriate for the risk level detected.

Key findings

You can prevent the most common types of session attacks by ensuring that session IDs and session cookies are protected:

Session IDs are unique identifiers that the web applications create and assign to users for the duration of their visit. The session ID remains the same for a period of time, but a new one should be created for each stage of the session.
Session cookies are files that contain the session ID. When users initially sign on to an application, a session ID and a session cookie containing that ID are created and sent to the user’s browser to provide access. The browser then sends the cookie with every request to the server, which verifies the session ID and retrieves the requested object. Session cookies are temporarily stored on the user’s device during a session and are typically destroyed when the session ends.

Session cookies are different from persistent cookies because persistent cookies exist after users close their browsers. Persistent cookies are used to recognize users and their devices, track their activity, display personalized ads, and create a better browsing experience by showing users other items that might interest them based on their browsing activities. The most common types of attacks, which are session hijacking attacks, man-in-the-middle attacks, and fixation attacks, occur when either the session ID or session cookies have been compromised.

Session hijacking

Session hijacking occurs when attackers eavesdrop on network traffic and steal or predict the target’s session ID, which enables them to impersonate the user, gain access to their sensitive information, and commit fraud and theft.

In this diagram, the attacker uses sniffer tools to obtain valid session IDs.

A diagram showing the attacker intercepting the session ID as the user is interacting with the application.

Then, attackers use these session IDs to access the application by impersonating the user.

This diagram shows the attacker using the session ID to access the application.

It is especially easy for attackers to eavesdrop on open, unencrypted wireless networks, such as the free WiFi offered at coffee shops and other businesses. Laptops or mobile devices broadcast a request to the WiFi device in the room that receives the signal, but these broadcasts are also visible to any other device in the room, including eavesdropping attackers.

Man-in-the-middle attacks

Man-in-the-middle attacks occur when attackers impersonate either the user or the application and make it appear as though normal communication is in progress. Their goal is to steal sensitive information, such as sign-on credentials, credit card numbers, and financial account details.

First, they find a way to impersonate the original connection, then they communicate with the user, and finally, they access user accounts. These types of attacks can be compared to your mailman opening your bank statement, obtaining your account information, resealing the envelope, and delivering it to your door.

This diagram shows the attacker impersonating the original connection.

Fixation attacks

Fixation attacks occur when attackers steal valid session IDs that have not yet been authenticated. Attackers send users a link that contains the session ID and tricks them into clicking on it. When they authenticate with what they think is the application, the attacker uses the same session ID to access user accounts.

This diagram shows the attacker sending the user a link. The user clicks on the link to access what they think is the application. The attacker uses that session to access the application.

Recommendations

Because the ways in which application sessions are handled can affect the user experience, it’s important to get it right. You want to keep session data safe from attackers, but you also want to ensure that users enjoy interacting with your applications and aren’t unnecessarily interrupted during their journeys with authentication requests. The more your users enjoy their experiences, the more likely they are to become loyal customers, have stronger emotional connections to your brand, and refer other customers, which will ultimately increase your revenue.

For example, most people understand why financial institutions require multi-factor authentication (MFA) and have shorter timeout sessions and expirations, and they appreciate the fact that protection efforts are in place. However, many other types of organizations are not concerned with protecting sensitive information until purchases and other transactions are made or relationships are established. They are focused on engaging their users and making applications easy to access and use, which usually means that their sessions are much longer-lived and more complicated to protect.

While no solution is perfect and some level of risk will always exist, we’ve created a list of best practice planning and implementation recommendations, and provided some session configuration suggestions, to help you keep your sessions as secure as possible.

Planning and implementation recommendations

Many tend to overlook the importance of the planning process when large amounts of time, effort, and energy can be saved if session management is appropriately planned and implemented. We recommend the following:

Include the appropriate stakeholders in your decision-making processes. Often, identity and access management (IAM) administrators and engineers begin defining session parameters without consulting others who will be affected by configuration decisions, such as product managers, marketing and support representatives, and application owners.

It’s best to work closely with these stakeholders from the beginning to ensure that you all understand the current and future state of user journeys and that you’re all involved in the decisions made regarding these journeys. Consider using an orchestration tool to help you visualize each path users can take.
Review process flows to ensure that authentication occurs at the appropriate time and place. Consider the sensitivity of the data involved in each interaction and determine what type of security is needed.

There are many ways you can configure application sessions to best meet your needs. For example, you can create rules that drive authentication and determine what users can see and do in an application, or you can map re-authentication methods to actions taken based on risk tolerance and levels of identity assurance.
Continually monitor your sessions to determine whether they can still be trusted. Track as many interactions as you can and obtain data feeds from as many systems as possible. This data can help you identify patterns in normal behavior so that you can more easily detect abnormal activity. You can use API detection solutions to identify suspicious activity, monitor user behavior, and compare it to known patterns. You might also consider using telemetry monitoring to help you detect irregularities.
Use risk-based authentication, which requires users to provide additional authentication information if risk signals are detected. The risk level is determined by several unique factors including location, time of day, device and browser information, IP address, user information, and the context of the request.
Determine what will happen when abnormal activity is detected. Will you end the session? Require users to re-authenticate? Require users to authenticate using a different method? Map out these remediation processes during the planning process and test them before implementation. Orchestration tools are also helpful in mapping out these processes.
Use passkeys, if appropriate. Passkeys are a safer and easier alternative to passwords. With passkeys, users can sign on to apps and websites with a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern, freeing them from having to remember and manage passwords.

After you and your team implement your session configurations, the real work begins. Continue to review the data you collect and revisit your authentication processes on a regular basis. The threat landscape is constantly evolving, and it’s important that you evolve with it. Technologies change quickly and new attack techniques will continue to emerge, so the session configurations that you establish today might work well, but might not work quite as well tomorrow.

Session configuration recommendations

Hijacking attacks, man-in-the-middle attacks, and fixation attacks most often occur when either the session ID or session cookies have been compromised. To protect them as much as possible:

Use HTTPS instead of HTTP

When HTTPS is used, all communication between the user’s browser and the application is encrypted, which means that even if an attacker manages to intercept the traffic, they cannot read or tamper with the data. HTTPS also provides authentication, which ensures that users are communicating with the real application and not a fake application set up by an attacker.To protect cookies, we also recommend enabling the following attributes:

The Secure attribute so that they will only be sent over HTTPS.
The HttpOnly attribute so that JavaScript cannot access the cookies, which prevents attackers from stealing them using cross-site scripting (XSS).

Create secure session IDs and cookies

To ensure that attackers can’t predict session IDs, it’s considered an industry best practice to randomly generate session IDs that are a unique combination of letters and numbers at least 128 bits (16 bytes) long. This ID is simply an identifier and should not contain sensitive information.When the session ID is created, a session cookie is also created to store the ID. It’s a good idea to store session IDs in a different cookie from other sensitive information, such as a username. That way, even if an attacker manages to obtain the cookie, they won’t be able to hijack a session without knowing the username.It’s also a good idea to encrypt session IDs so that attackers cannot read them without having the encryption key.

Limit the number of simultaneous sessions per user

If an attacker were to gain access to a user’s account, they could do whatever they want. However, if you limit the number of simultaneous sessions available to each user, the application will only be available from one device at a time. This doesn’t mean that users can only access the application from one device. It means that users can only be signed on to one device at a time.

Regenerate session IDs

To protect session IDs, we recommend regenerating them after users sign on to the application because it makes it much more difficult for hackers to exploit session IDs. It’s also important to regenerate session IDs when users’ privileges change.If a hacker hijacks a user’s session, they will have access to the user’s account with all of the privileges that the user has. However, if the session ID is regenerated after a significant privilege change, the hacker will no longer have a valid session ID, which makes it more difficult for them to access the user’s account and escalate their privileges within the application.There are two ways to regenerate session IDs:

The first is to invalidate the old session ID and create a new one. This approach is the most secure, but it can cause problems if the user has multiple tabs open because they will be signed out of all of them.
The second is to change the secret key associated with the session ID. This approach is less secure but provides a better user experience because it doesn’t sign the user out of other open tabs.

Destroying the session ID when users sign off is also highly recommended, as you invalidate the session ID and make it much more difficult for an attacker to hijack the session.

Invalidate all open sessions when passwords change: If an attacker obtains a user’s password, they could use it to access the user’s account. However, if all open sessions are invalidated when the password change occurs, the attacker will be locked out of the session.
Expire sessions based on user inactivity and risk tolerance: The longer sessions last, the more vulnerable they can become. The amount of time sessions should last depends on the sensitivity of the information exchanged between the user and the application and the level of identity assurance.For example, an e-commerce retail company might not have any concern about their users being signed on for long periods of time, especially if the user is just browsing and hasn’t authenticated with the application. However, most financial institutions do not allow their users to be inactive for longer than 15 or 20 minutes before the session expires as the risk of fraud and theft increases.

To learn more about session management and authentication, see:

To learn more about monitoring solutions, see:

Use Cases