← Back to guides

Database-backed sessions: expiry, revocation, and secure cookies

A database-backed session gives the client an opaque random token while the server stores a protected token hash and session state in the database. Unlike a self-contained browser token, the session can be revoked immediately, disabled with the user, limited by idle time, and inspected without trusting client claims.

The browser holds one opaque credential

For web applications, place the raw session token in a Secure HttpOnly cookie with SameSite protection and a narrow path. Browser JavaScript should not read it. Mobile applications should use the operating system's protected credential storage and send the token only to the application backend over HTTPS.

session-cookie.ts
response.cookies.set("own_auth_session", sessionToken, {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",
  sameSite: "lax",
  path: "/",
  expires: session.expiresAt,
});

Verify at every trusted server entry point

current-session.ts
const result = await auth.verifySession({ token: sessionToken });
if (!result) return null;

return {
  user: result.user,
  session: result.session,
};

A navigation redirect is not authorization. Route handlers, server actions, loaders, jobs, and data-access functions must verify the session and check permission to the requested record.

Use both absolute and idle expiry

  • Absolute expiry limits the maximum lifetime even when the account stays active.
  • Idle expiry ends sessions that have not been used within the configured window.
  • Revocation ends one device or all devices before either timer expires.
  • User disablement must make every session ineffective immediately.

Revocation is the reason to keep state

Password changes, suspected compromise, staff action, and user-requested sign-out should revoke affected sessions in the database. The next verification fails without waiting for a client token to expire. Store safe device and last-used metadata when it helps users recognize sessions, but never return token hashes.

Clean up without weakening verification

Expired and revoked rows can be deleted according to retention needs, but verification must reject them before cleanup runs. A delayed cleanup job is an operational concern, not permission for an expired session to become valid again.