Session Lifetime

Every session should have a server-enforced expiration, commonly stored in an expires_at column. Without a well-defined lifetime:

• A stolen session may remain useful for far too long.
• Old, still-valid sessions accumulate across devices.
• Clearing one browser's cookie can leave copied session IDs valid on the server.

The server must enforce the expiration. A client-side expiration timestamp helps the browser know when to discard its copy, but an attacker can always bypass browser behavior.

As you can expect, there's a tradeoff here. Short-lived sessions reduce the time an attacker can reuse a stolen session, but they also force users to reauthenticate more often, which is annoying.

Long-lived sessions are more convenient, but they increase the damage window when they're stolen.

There's no single "correct" duration. The right choice depends on what the user is doing, the device, and the damage a stolen session could cause. Applications often combine two limits:

• An inactivity timeout ends a session after no activity, for example, 24 hours.
• An overall timeout caps the session's total lifetime, for example, 30 days.

Different actions carry different levels of risk. For example:

Higher-risk actions should require fresher trust.

Expiration isn't enough. You and your users need to be able to revoke access when you suspect a session may be hijacked. Revoking a session means invalidating it immediately. There are also times when a server should automatically revoke sessions, like when a user logs out. It's not enough to just clear the browser cookie.

This is where stateful sessions shine. A server can revoke a session by invalidating its record. A self-contained stateless token can't be individually revoked. That problem can be mitigated (but not eliminated) by short token lifetimes and refresh tokens that can be revoked.

Bearly Secure clears the browser's session_id cookie when a user logs out, but the server-side session record is still valid. If an attacker saved the session ID before logout, they could keep using it until the session expires!

Update logout so it revokes the current server-side session.

1. In src/auth/sessions.ts, fix getCurrentSession so it invalidates revoked sessions.
2. In src/routes/auth.ts, import the provided revokeSession function from ../auth/sessions.ts.
3. Then update POST /logout so it begins by:
   1. Getting the current session from the request cookie.
   2. Revoking the current session if one exists.
4. Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.