Managing Sessions With a Backend Server

After a user authenticates, you'll typically want to create a session to persist the user's authenticated state across requests between the browser and your web application. For web applications with a backend server, there are generally two approaches to session management: client-side and server-side.

Client-Side Sessions

Client-side sessions store all session data in 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.

One limitation of this approach is that most browsers enforce a maximum cookie size of 4 KBs, so if your session data exceeds this limit, you'll need to split it 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 tokens in the session cookie. When validating the session cookie on the server, verify the access token's expiration time to ensure 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 using this approach, the user's session can be indirectly invalidated by revoking the refresh token; however, it's important to note that there may be a delay between when the refresh token is revoked and when the session is invalidated, depending 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 store all session data in an external datastore, such as Redis, with only the session ID stored in the session cookie. When the server receives the session cookie, it uses the session identifier inside the cookie to retrieve the full session information from the external datastore. Server-side sessions are useful for applications with large sessions that exceed the 4KB cookie limit. They also provide greater control over session revocation, as sessions can be revoked immediately by deleting them from the external datastore. The main downside is that server-side sessions add extra latency to each request since they require an additional network call to fetch session data. Additionally, implementing server-side sessions is more complex because it involves setting up an external datastore for persistence.

Securing the Session Cookie

Whether you're using client-side or server-side sessions, you should always set the following cookie attributes in order to secure the session cookie:

1. HttpOnly - Ensures that the cookie can't be accessed by JavaScript running in the browser. This helps protect against cross-site scripting (XSS) attacks.
2. SameSite - The SameSite attribute should be set to Strict or Lax. This will stop the cookie from being sent during cross-site requests, helping to prevent cross-site request forgery (CSRF) attacks.
3. Secure - Ensures that cookies are only sent to the server over HTTPS.

Terminating Sessions on Logout

When an authenticated user logs out of your application, the application must ensure that all associated state is cleaned up. Typically, three items need to be deleted to log the user out properly: the user's Application Session, the refresh token, and the Wristband Auth Session.

Deleting the Application Session

Regardless of whether the session is managed client-side or server-side, the backend server must delete the application's 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 an associated refresh token, the application should call the Wristband Revoke Token API to revoke it.

Deleting the Wristband Auth Session

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

Accessing Session Data From Client-Side JavaScript

Typically, you'll need to expose the user's session data to your JavaScript code running in the browser; for example, to populate the authentication context in your React application. To do this, you'll need to create a Session Endpoint on your backend server that uses the contents of the session cookie to retrieve the user's session data and return it in the response. Your client-side JavaScript code can then call the Session Endpoint to get access to the user's session data.