Establishing a session, end to end

The flow#

1. Trigger — a sign-in completes, or an existing session is presented with a request.
2. User or external event — the browser sends its cookie. That is all it has; it holds no claims of its own about who you are.
3. Authentication and workspace resolution — the reference is looked up server-side, and the identity and workspace come from the record rather than from anything the browser said.
4. Ingest — the request continues only if the record is valid. An unknown or ended reference is not a partial session; it is no session.
5. Canonical record — the session names one person and one workspace. There is no session that spans two workspaces.
6. Reasoning — none. A session is looked up, never inferred from context.
7. Knowledge, memory and rules — scoped by the resolved workspace, like everything else the request touches.
8. Autonomy and approval — a person's approvals are recorded against their identity, which is why the session has to name a person and not merely a workspace.
9. Action through a provider — none. Sessions are internal; no provider takes part in one.
10. Result — the request is answered inside the resolved workspace, or refused before any handler runs.
11. Relationship, timeline and memory — unaffected. Sessions are not events in a customer's history.
12. Audit, usage and Needs You — actions taken during the session are attributed to the person it names, which is what makes the decision record answer 'who'.

What each side holds#

Keeping the authority server-side is what makes revocation meaningful. If the browser held claims — a name, a workspace, a role — ending a session would mean persuading the browser to discard something, and a browser that has gone offline with a valid token cannot be persuaded of anything. Here the reference is worthless the moment the record behind it stops being valid.

One session, one workspace#

A session resolves to exactly one workspace, and that resolution happens before any handler runs. Nothing later in a request can widen it: a query cannot ask for a second workspace's rows, because the filter is applied to every query the mapper builds and the database's own policy applies to the statement it receives. Resolving which workspace a request belongs to is that mechanism in full.

Somebody who belongs to more than one workspace therefore changes workspace by changing session, not by changing a setting inside one. That is a deliberate constraint: a request whose scope could move part-way through would make every isolation argument on this site conditional.

Ending one#

1. Sign out.

   Result The record stops being valid immediately. The cookie left in the browser refers to nothing, which is the point of it being opaque.

2. Sign in as somebody else on the same browser.

   Result The session it replaced ends — that browser only. Other devices are untouched, and treating this as a way to end somebody's access elsewhere is a mistake worth not making during an incident.

3. Let it expire.

   Result Sessions do not last for ever. An expired one produces a sign-in prompt rather than an error, and no work in progress is submitted on its way out.

What a session is not#

• It is not a permission. It says who you are and where; what you may do inside a workspace is decided separately.
• It is not an API credential. Programmatic access uses integration keys, which have their own lifecycle and are not a session in a header.
• It is not shared between people. Two colleagues in one workspace have two sessions, and the decision record depends on that being true.
• It is not a licence. Whether a capability is available depends on the workspace's plan, not on the session that reached it.

Questions#

Related#

• Sessions
• Signing in as somebody else
• Google sign-in, end to end
• Resolving which workspace a request belongs to
• You were signed out