DocsAuthenticationCardinal 0.7.0

Sessions and step-up

A session is a row with a validity period, and policy can demand a fresher one.

llms.txt

A session is a row with a validity range, like group membership: closing the range revokes it, and revocation is enforced when the session is read rather than only by evicting a cache.

The session cookie is HttpOnly and SameSite=Lax, and Secure outside development. Every mutation carries a CSRF token in a second, deliberately script-readable cookie: that pair is the double-submit, and only the combination is useful.

Both cookies are host-only, sent to Cardinal's own host and nowhere else, and over HTTPS they are named __Host-cardinal_session and __Host-cardinal_csrf. A browser accepts a __Host- cookie only from that host, so another site under the same parent domain cannot plant one. Single sign-on for applications behind the proxy uses a third cookie with a token of its own, which ends with the session (forwardAuth).

To end every session at once, with the database credential, which it finds the way cardinal-server migrate does (-dsn, CARDINAL_DSN or the configuration file):

cardinal-server sessions end-all

Everyone signs in again. Each person whose sessions ended has it in the journal, and access tokens are not sessions, so they keep working.

Two limits, not one

[sessions]
idle = "8h"
absolute = "7d"
admin_window = "15m"

Idle expiry ends a session that has stopped being used. Absolute expiry ends it regardless, so a session that is kept alive by a background tab does not live forever.

The third, admin_window, is not a session limit; it is how long a security key touch keeps administration open, and the next section is about it. The server logs all three at startup, as strings rather than durations: slog renders a time.Duration as nanoseconds, and "28800000000000" is a number nobody reads as eight hours.

Step-up

Policy reads two things about how somebody authenticated: whether the credential was device-bound, and how long ago. So a rule can demand a fresh ceremony for a privileged action without any special machinery:

action what the shipped policy demands
administering the directory device-bound, within the administrative window (15 minutes unless configured)
issuing an SSH certificate device-bound
becoming root on a host within 15 minutes

The administrative window is counted from the key's last use and is not extended by activity, so a laptop left open in the middle of administering stays able to administer for at most that long. While it is open, the console's header says until when, and Lock now closes it without signing out.

When the API refuses for this reason it says so, naming the window, and the console's step-up endpoints run the ceremony without creating a second session. Those endpoints are rate-limited like login, because a step-up is a login in everything but the session it does not create.

Revoking

A person's own sessions are listed under Access → Connected, and cardinal user disable revokes every session and access token an account has. A terminal's session, approved from the console, lasts like the console's from Cardinal 0.7.0, appears in that list as a terminal, and ends when the browser session that approved it signs out; cardinal logout ends it from the terminal. What keeps a stolen one from administering is the administrative window, as for a stolen cookie.