Sessions and step-up
A session is a row with a validity period, and policy can demand a fresher one.
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.