Managing Sessions With a Backend Server

For web applications using a backend server, there are generally two approaches for managing sessions: client-side sessions and server-side sessions. For both methods, a session cookie is involved. To adequately protect the session cookie, it should have the following attributes: HttpOnly; SameSite=<Lax|Strict>; Secure;.

Client-Side Sessions

Client-side sessions are where all of the session data is stored inside a session cookie. This approach is useful if you don't want to worry about storing session data in an external datastore. Before the session data is stored in the cookie, it must be encrypted. Encrypting the cookie contents prevents sensitive data from being exposed through the cookie and also stops unwanted tampering with the cookie's value.

One limitation of this approach is that most browsers enforce a max cookie size of 4 KBs, so if your session data exceeds this size, you'll need to split the data across multiple cookies or use server-side sessions. Also, with client-side sessions, it's not possible for an external party to immediately revoke a user's session since they don't have access to the session cookie. To work around this limitation, it's advisable to include the access and refresh token in the session cookie. When validating the session cookie on the server, the access token expiration time should be verified to ensure that it hasn't expired. If the access token has expired and can't be refreshed using the refresh token, then the session should be considered invalid. By utilizing this approach, the user's session can be indirectly invalidated by revoking the refresh token; however, it's important to note that there could be a delay between when the refresh token is revoked and when the session is invalidated based on how long it takes for the access token to expire. Therefore, it's best to use short-lived access tokens to minimize this delay.

Server-Side Sessions

Server-side sessions are where all the session data is stored in an external datastore (such as Redis), and only the session ID is stored within the session cookie. When the server receives the session cookie, it uses the session identifier contained within the cookie to look up the complete session information from the external datastore. Server-side sessions are useful for applications with large sessions that can't fit within the 4KB size limit of cookies. Also, server-side sessions provide more control over session revocation since the sessions can easily be removed from the external datastore to invalidate the session. The main downside to using server-side sessions is that they add extra latency to each request to look up the session information from the external datastore. Furthermore, server-side sessions are also more complicated to implement since they require setting up an external datastore to persist the sessions.

Ending Sessions on Logout

When an authenticated user logs out of your application, the application must ensure that all sessions and their corresponding tokens are revoked.

Deleting the Application Session

Regardless of whether the session is managed client-side or server-side, the backend server must delete the session cookie. Deletion of the session cookie can be done by setting the max-age attribute to 0 and setting the cookie's value to an empty string. Additionally, the corresponding session data should be removed from the external datastore if server-side sessions are used.

Revoking the Refresh Token

If the session has a refresh token associated with it, then the application should call the Wristband Revoke Token API to revoke the refresh token.

Deleting the Wristband Authentication Session

Lastly, the application should redirect to the Wristband Logout API, which will cause the Wristband authentication session to be deleted.