Session management: terminating and rotating sessions

A console session is the short-lived, signed cookie the engine issues after a successful login, so the browser does not re-run the passkey or identity-provider ceremony on every request. This page is for a self-hoster who needs to respond when something goes wrong with one: a laptop is lost, a phone is stolen, or a team member leaves and their access must end cleanly and now.

There are three ways to terminate sessions, each with a different scope and a different person allowed to run it. The right one depends on whose sessions you need to end and why. This page explains all three actions, the two bounds that limit every session regardless (a twelve-hour absolute cap and a two-hour idle timeout), and how session termination relates to switching off an identity provider.

A session is a signed cookie with a hard ceiling

The engine does not keep a server-side table of live sessions. A session is a server-signed token of the form body-then-MAC, where the MAC is HMAC-SHA-256 over the body keyed with a signing key the engine generates once and keeps inside its Durable Object. Verification happens inside the Durable Object over a key that never leaves it, and the body is never trusted until its MAC verifies, so a forged or tampered token cannot set an email or extend an expiry.

Two properties of this model matter when you are responding to an incident.

The first is the session lifetime, which has two separate bounds. The outer bound is an absolute expiry set once at mint, twelve hours out, and never slid forward past that ceiling, so a leaked cookie is useless by the next working day no matter what. The tighter bound is an idle timeout: a session that sees no activity for two hours is rejected at the verify gate independent of the twelve-hour cap, so a leaked but unused cookie stops working after roughly two hours of inactivity, well before that next working day. An active session is kept alive by a sliding re-mint that runs about every fifteen minutes and refreshes the session’s last-activity marker, but the re-mint preserves the original issue time and the absolute expiry, so it can never push a session past the twelve-hour cap. The cookie is also HttpOnly so script cannot read it, Secure so it travels only over HTTPS, and SameSite=Strict so it is never sent on a cross-site request.

The second is that the role is never carried in the token. The session body holds identity, the verified email and the stable subject the role table keys on, but never the role or the capabilities. The engine re-resolves the role from its own tables on every single request. This is why a demotion or a removal takes effect on the very next request rather than waiting out the cookie: lowering someone’s role immediately changes what their existing session can do.

The three termination actions

The passkey column is step-up re-authentication, and the split in it is deliberate rather than incidental. The two actions that reach a session which is not the caller’s own are gated; the self-scoped one is not. A stale session that survived a suspected compromise could otherwise sign the legitimate operator’s other tabs out and leave them unaware anyone else was acting, which is the exact profile the gate exists for. Signing out your own other sessions bumps only your own epoch, so it stays friction-free for the case you reach for after losing a device. A bare break-glass token session and a Cloudflare Access session are exempt from the gate, as they are everywhere else.

Sign out my other sessions

This is the self-service action for “I am still here, but sign out everywhere else”, which is what you reach for after losing a second device you were signed in on. The engine bumps your own session epoch, which invalidates every session minted for your email before the bump, then re-mints your current session carrying the new epoch and re-issues that cookie. The result is that your other sessions die on their next request while the tab you are working in stays alive. A bare-token break-glass caller has no first-party session to manage, so it is refused.

Sign out a member’s sessions

This is the admin action for ending one named member’s sessions without touching anyone else, for example when a colleague reports a stolen phone. It is gated on roles.write, so an owner or an access-admin can run it. The engine bumps the target email’s session epoch so all of their email-keyed sessions die on the next request, and for a member who has authenticated through an identity provider it also bumps the per-subject revocation axis, so their identity-provider sessions die too and not only the email-keyed ones. An access-admin can terminate any non-owner member’s sessions, but only an owner may terminate an owner’s sessions.

Sign out everyone

This is the account-wide reset, the in-account equivalent of a global sign-out, for when you suspect the signing key or a session has been compromised. It is owner-only.

Because it rotates the one signing key for the whole account, signing everyone out is reserved to an owner. The engine re-resolves the caller’s role and requires owner, on top of the roles.write gate, so an access-admin cannot sign the whole account out.

Logout and offboarding fail a session closed on the next request

Two everyday events also end sessions, and both work by bumping the session epoch so the affected tokens fail closed at the verify gate, rather than relying on a client-side cookie clear.

An explicit logout is a real server-side termination, not merely a cookie clear in the browser. The engine resolves the identity from the presented token, then bumps the per-email epoch and the per-subject not-before instant. The just-logged-out token, and any copy of it that was exfiltrated, then fails closed on its next request. The browser also drops the cookie, but the server-side bump is what makes the logout meaningful against a stolen copy.

Offboarding a member, removing their role entirely, terminates their sessions for the same reason. Removing the role only downgrades the member to viewer on the next request, which would leave a read surface live for up to the 12-hour ceiling. So offboarding also bumps the per-email epoch and, for a bound member, the per-subject not-before instant, so the next request from any of their sessions fails closed at the verify-time gate.

Ending a session is not the same as ending a way in, and this page only claims the first. A role removal terminates what the person holds now; it leaves the passkey credential they enrolled, any recovery codes they banked and any unredeemed invite in their name untouched, so they can authenticate again and open a session the epoch bump has no quarrel with. Revoking those is a separate act with its own guards, on the Roles and access tab under Sign-in factors, and on the admin API as POST /admin/signin-factors/revoke. Offboard a member is where it and the reasoning for keeping it separate live.

How this composes with switching off an identity provider

Session termination and identity-provider revocation are independent mechanisms that compose. The session epoch axes above govern sessions by email and by subject. There is a separate axis keyed on the identity-provider connection, the idpEpoch. Disabling or deleting an identity-provider connection stamps that connection’s epoch, which independently kills every live session that was minted through that connection on its next request, and the verifier additionally re-checks at verify time that the connection still exists and is still enabled.

This means you have two clean ways to cut access for someone signing in through SSO. You can terminate their sessions by member, which bumps their email and subject axes, or you can disable or delete the whole connection, which bumps the connection axis for everyone who signs in through it. The two are described from the SSO side in test, troubleshoot and revoke SSO.

There is one more property worth knowing for an identity-provider session. The member’s groups are snapshotted per subject at sign-in and re-read on every request, and are never carried in the session cookie. So a group change, or a deprovision at the identity provider, takes effect on the next request without waiting out the 12-hour cookie, exactly as a role change does. The cookie carries identity, never groups and never the role.

Where the actions live

The console surfaces all three actions on its access and security screen, calling the engine routes below. The engine is always the enforcement point; the console only mirrors its rules so a button is never a dead end.

Where this fits

• Test, troubleshoot and revoke SSO covers disabling or deleting an identity-provider connection, the independent idpEpoch axis that kills that connection’s sessions.
• Offboard a member is the end-to-end departure runbook, of which the session termination here is one step.
• Roles and capabilities defines roles.write and confirms that the role is re-resolved per request rather than baked into a session.
• Account compromise eviction is the broader incident response, where terminate-all is one lever among several.

Last updated 4 August 2026.