Sessions

Logging in creates the following cookie.

__Host-runlot_auth=v1.<random 32 bytes>; Secure; HttpOnly; SameSite=Lax; Path=/

The default session lifetime is 30 days.

runlot auth set session-days 7

Server sessions, not signed tokens

The cookie holds a random value, not a signed token. The server hashes that value and looks the session up in a table. It costs one extra lookup, but revoking a session ends the login immediately. With signed tokens alone you would have to wait for the token to expire.

await env.auth.sessions.revokeAll(userId);   // Immediately revokes every session for this user

Using sessions outside the browser

From a mobile app or a server, you can send the session value in this header.

Authorization: Bearer v1.<the same value>

The Authorization header takes precedence over the cookie. Requests that use this header are not subject to the CSRF check.

Logging out

return new Response(null, {
  status: 302,
  headers: { location: "/", ...(await env.auth.signOut(request)) },
});

From a browser form you can also post to POST /__runlot/auth/sign-out. Both approaches delete the row in the session table and clear the cookie.

Inspecting sessions in the database

select user_id, created_at, last_seen_at, expires_at
from runlot_auth.sessions
order by last_seen_at desc
limit 20;

Tokens are stored only as hashes. last_seen_at is updated once a day rather than on every request, so that read requests do not cause a write.

Expired sessions are cleaned up once every 100 login checks.

What session cookies require

Because the cookie name starts with __Host-, it is only sent over HTTPS. Deployed addresses always use HTTPS. Sessions are not kept on a screen opened from a local HTTP address.