Everything measurable passes, everything that can be counted has an end. Only three things are infinite: the sky in its stars, the sea in its drops of water, and the heart in its tears.
—Gustave Flaubert, French novelist, from The Letters of Gustave Flaubert (1980)
A user’s interaction with an application over a period of time is known as a session. Upon authenticating to an application, a user expects to navigate through the application and perform various transactions during their session without having to authenticate every time they do something. In order to make this possible, an application needs a way to track that a user has been authenticated. Data about whether, when, and how a user has authenticated may be tracked by an application along with other information it maintains during a user’s session. Sessions and session state may be handled differently for web applications, single-page applications, and applications that run natively on a device, such as mobile applications. In this chapter, we’ll describe where sessions exist, session expiration, and renewing sessions.
Application Sessions
During a user’s session, an application may need to track particular information such as in-flight transactions or how long a session can continue. With traditional web applications, the user’s session state may be maintained on the server by assigning it a session identifier and storing it in memory, a filesystem, database or shared service like Redis.1 The session identifier can be stored in a cookie set by the application, which is then sent by the browser with each request to the application server. When a request is received, the server can use the session identifier from the cookie to retrieve the user’s session information and process the request. Sometimes, if the session data is small enough, it may all be stored in the cookie, eliminating the need for server-side storage.
Traditional web applications often limit the time for which they retain a session. Session information maintained on a server typically consumes server resources. If a user abandons a session by forgetting to log off or a client loses its connection to a session for some reason, server resources would be wasted. In addition, a session left open and forgotten on a user’s computer invites some risk of potentially being taken over by a malicious actor. As a result, traditional web applications often implement a session timeout which effectively limits how long a user’s session can last. Session timeout might occur after a period of inactivity and/ or a maximum period of time, with the allowed session duration in either case often based in part on the sensitivity of the application and data involved.
With single page applications and stateless back-end APIs, server-side sessions for users are no longer required, but the concept of a session timeout persists for other reasons. Applications are still vulnerable to the possibility that a session left open for an extended period might be hijacked. This concern is especially relevant for applications handling sensitive data, many business-facing applications, and applications accessed from shared devices. Having a user reauthenticate when a session times out provides some assurance that the authorized user is still in control of the device and session. As applications increasingly leverage identity providers, a user’s reauthentication can renew an identity provider session leveraged by many applications, meaning a user might not have to actively reauthenticate to every application.
Native applications running on mobile devices have additional considerations. The small form factor and input mechanisms on mobile phones make frequent reauthentication a significant detractor to user experience. Especially for some consumer-facing applications, it is desirable to remove barriers to usage and make it easy for users to stay logged in as long as possible. Native applications often use stateless APIs resulting in little server-side cost for allowing a user’s native application session to continue for an extended period of time. Sensitive applications, such as banking applications, often still implement a session timeout on mobile devices, but less-sensitive native mobile applications may allow a session to continue for an extended period, until a user explicitly logs out.
Identity Provider Sessions
Identity providers also need to maintain a session for a user as a mechanism to remember and recognize an authenticated user across multiple requests. One solution is to create a session object with a session identifier and attributes such as an identifier for the user, the authentication mechanism used, the time of authentication, and when the session will expire. An identity provider can create a cookie in the user’s browser that contains all the session information or just a session identifier that maps to a server-side session data store. The browser then sends the identity provider cookie with every request to the identity provider. When a user is redirected to the identity provider, it uses data from the cookie to detect if a user already has an authenticated session.
This scheme helps an identity provider recognize users it has authenticated. After successfully authenticating a user, the identity provider sets or updates in the user’s browser a cookie with session information and returns a security token to the application. The application may then create or update its own application session for the user. When the application session expires, the application can check the status of the user’s session at the identity provider. It may do this by redirecting the user’s browser to the identity provider. Such a request will include any cookies set previously by the identity provider, which contain the user’s session information. If the user’s session at the identity provider is still valid, the identity provider returns a new security token to the application without forcing the user to authenticate again. Some identity providers may support alternative mechanisms for checking the status of the user’s session at the identity provider which can enable an application to avoid a browser redirect when the user’s identity provider session is still valid. Of course, if the identity provider session has expired and the user needs to reauthenticate, the user will need to be redirected to the identity provider.
Multiple Sessions
Architectural Layers Where User Sessions May Exist
Session Duration
Each session established for a user can be terminated at different times and for various reasons. Sessions may time out if they are established with a specific duration. A session may have an idle timeout where the session is invalidated if the user has been inactive for a period of time. A session may also have a maximum session time limit which ends the session after a period of time regardless of the user’s activity level.
With an idle session timeout, if a user takes certain types of actions tracked by the application, the idle session timer gets reset, which extends the session. Activity in an application may reset an application session’s idle timer, but not be visible to an identity provider and consequently not reset an idle timeout at the identity provider. The identity provider’s idle timeout is typically only reset by requests visible to it, such as an authentication request from an application.
If an application enforces an idle session timeout, it can be disruptive to a user to suddenly lose an application session, especially if the user was in the middle of entering a lot of data for a transaction! An application can mitigate the potential for bad user experience by tracking the session duration, providing a warning to users before the session times out, and resetting the idle timeout if the user indicates they wish to continue. Proactively prompting the user when a session timeout approaches and letting them renew their session can avoid bad user experience when enforcing an idle timeout is required.
The appropriate session duration time for an application will vary based on factors such as the sensitivity of the application or the delivery platform. For an idle timeout, it may help to consider how long you would want to tolerate a user’s session remaining open if the user walks away from their desk with the application open. For applications on mobile phones carried around by their owners, it may be less likely for an open application session to be physically accessible by others. For a maximum session timeout, it may help to evaluate how frequently or infrequently the user should reauthenticate to confirm they are still in control of the session as well as how frequently user profile information might need refreshing. It’s a balance between protecting the user and data they access and annoying the user by requiring them to authenticate too frequently. The duration may differ for applications run on desktop/laptop computers vs. mobile phones and for consumer-facing applications vs. enterprise applications as well as for applications with data of different sensitivity levels. It can often take some trial and error to get it just right.
Sessions may end for reasons other than a timeout. A user may explicitly log out. This is covered in more detail in Chapter 13. An administrator may terminate a user’s session at an identity provider for various reasons, such as in response to a report of a compromised credential. A user’s session might be terminated if a server is restarted. A user’s session might exist at a server, but be irretrievable if the user deleted the cookies in their browser that contain information about their session. The possibilities for session termination should be considered in application designs with appropriate actions defined for each case.
With many ways for sessions to terminate, and multiple sessions in the mix, it is important for application designers to specify or understand the impact on other sessions when any session is terminated. For example, if an application session expires, should it request the termination of the user’s session at an identity provider? If a user’s identity provider session is terminated, should that trigger the immediate termination of a session in a related application using the same identity provider? The options to consider may be constrained by identity provider policy when an identity provider is controlled by an external party, but designs should still enumerate what happens for different session termination scenarios.
An application may want to periodically check the status of a user’s session at an identity provider. This may be done so the application can terminate its own session when the identity provider’s session has ended. This may also be done when an application’s session for a user has timed out, with the application checking the state of the user’s identity provider session as part of its own session renewal process.
Session Renewal
When an application’s session for a user expires, the application may wish to enable the user to renew the session. It can do this by redirecting the user back to the identity provider. The identity provider can authenticate the user if it doesn’t have a valid session for them and return new security tokens to the application per the parameters in the application’s authentication request. If the user’s identity provider session is still valid, the user would not need to reauthenticate, and the application would receive new security tokens based on the user’s existing session. The application can then use information in the new security tokens when renewing the user’s application session.
Applications can use parameters in an authentication request to suppress or force active authentication. It may be desirable, for example, to have reauthentication occur if a certain amount of time has passed since the user last actively authenticated. With OIDC, the optional “prompt” parameter can be added to an authentication request to force or suppress authentication at the OpenID Provider. The optional “max_age” parameter can be used to control how long a user can go without actively reauthenticating. Applications using max_age should still check the auth_time claim in the ID Token to ensure the requested max_age was followed. Use of max_age and auth_time is useful if an OpenID Provider has a relatively long maximum or idle timeout, and a particular application wishes more frequent authentication. With SAML 2.0, applications can use the “ForceAuthn” attribute of the authentication request to force the identity provider to actively authenticate the user. Such authentication request parameters give applications some measure of control over whether the user is actively reauthenticated when they are redirected to the identity provider.
Individual identity providers may support alternative methods for checking the status of a user’s session at the identity provider. If a user has a valid session at an identity provider, such methods may enable renewing an application session without requiring a browser redirect. If a user’s identity provider session is no longer valid, the user can then be redirected to renew the identity provider session.
Token Renewal
In addition to renewing a session, an application may need to periodically renew a security token. The application may have received an ID Token and possibly an access token to call an API. An application may wish to periodically request a new ID Token to ensure it has up-to-date claims for an authenticated user. An application may wish to request a new access token because it needs to call an API and the access token it requested previously has expired. It is considered a best practice in many cases, and especially with public clients, to issue access tokens with short expiration times, and renew the tokens when needed, so the need for new tokens may occur throughout a user’s session’s existence.
During an application session, an application can renew an ID Token or access token it previously obtained from an OpenID Provider using a couple different mechanisms, based on the type of application. Traditional web applications and native applications may be able to obtain a refresh token for use in renewing ID Tokens and/or access tokens, but they are not required to do so. Using a refresh token to renew tokens avoids the need to interrupt the user experience, but back channel requests with a refresh token may not update the identity provider’s session cookie, resulting in a faster idle timeout. Single-page applications implemented as public clients cannot securely store and handle refresh tokens so must use an approach that doesn’t rely on refresh tokens unless their authorization server implements measures against leaked refresh tokens such as refresh token rotation or sender-constrained refresh tokens.2 Applications that do not receive refresh tokens can redirect the user to the OpenID Provider when new tokens are needed. If the user has a valid session, the application will receive new tokens. If the user does not have a valid session, the request will trigger authentication and consent as needed. Even applications with refresh tokens may want to use the redirect approach periodically to update the identity provider’s session cookie and idle timeout.
Redirecting the user to the OpenID Provider and back, however, involves challenges as it can interrupt the user experience. With single-page applications, this can result in the loss of a user’s work unless the application saves it and restores it after the return from the OpenID Provider. One improvement is to do the redirect using a hidden iframe in the application and setting the “prompt” parameter to “none” to avoid interrupting the user experience. If the user has a valid session, the application will receive new tokens. If not, the application will receive an error response and can redirect the user again without the “prompt=none” option to trigger authentication. An OpenID Provider may provide an SDK to make this easier for applications.
Reconstituted Sessions
It can be disruptive to users to have their session time out frequently in heavily used applications if they have to reenter several selections when they reauthenticate. An application that needs a session timeout and falls in this category may want to provide an improved user experience by offering a session that can be reconstituted after session timeout. With this scheme, upon session timeout, the system invalidates the session for further use, but retains a memory of the session and the identity associated with it, so that the session state can be restored to its former state if the user actively reauthenticates. Such a session is terminated and permanently deleted by an active user logout, not a session timeout. That said, it is still desirable to have a limit for how long a session stays in a dormant state, to reduce backward compatibility issues and to avoid storing session data for sessions orphaned by events such as a user deleting session cookies.
Summary
Applications maintain sessions for users during a user’s interaction with the application. If applications delegate authentication to an external identity provider, there may be multiple sessions for the user at different layers within the solution architecture. Each component maintaining a session for a user may have one or more types of session timeout. Sessions are a key enabler for single sign-on, which just so happens to be the topic of the next chapter.
Key Points
A user’s interaction with an application for a duration of time is a session.
Session state may contain data about the user and authentication event.
In solutions with single sign-on, a user may have multiple authentication sessions.
Sessions may be subject to an idle and maximum timeout.
Session duration is typically based on the sensitivity of the resources accessible from the session, the application delivery platform, and the type of application.
A continuous authentication session can be used to remember and reconstitute user sessions which have expired.