Session Management

Every time you log in — with a password, PKI/CAC certificate, or a social provider — brewlytics issues you a tracked session backed by a persisted record on the server, not just a JWT the browser holds and forgets. That record is what lets the platform show which sessions are active for a given login, apply layered timeouts to each one, and revoke a session outright when it shouldn’t be trusted anymore.

Viewing and Revoking Your Own Sessions

The self-service session API is live: GET /api/auth/sessions lists your own active sessions, and DELETE /api/auth/sessions/{jti} revokes one of them by its token id. Each row in the response includes the derived timeout deadlines described below, computed for that session’s host.

There isn’t yet a self-service page in the app for browsing or revoking your own sessions from the UI — if you need to end a session today (for example, after using a shared machine), sign out from that session directly, or reach out to an administrator, who can revoke it from the admin console. See the sessions tag on the API Reference page if you want to call the self-service endpoints directly.

Administrators have additional fleet-wide session controls, available through the admin console.

Session Lifetimes

A session doesn’t just expire once — it’s bounded by three independent, layered timeouts, each configurable per host:

• Access lifetime (access.ttlSec, default 15 minutes) — how long the current access token is valid before the browser must refresh it.
• Idle timeout (idle.timeoutSec, default 30 minutes) — how long the session can go without activity before it’s no longer refreshable, even if the access token itself hasn’t expired.
• Maximum lifetime (maxLifetimeSec, default 24 hours) — a hard ceiling measured from the original login, after which the session ends regardless of activity. A deployment can disable this ceiling entirely by setting it to zero or a negative value.

Each of these can be overridden for a specific host, so a deployment can run tighter timeouts on a more sensitive endpoint without changing the defaults everywhere else. Whichever deadline comes first — access refresh, idle timeout, or the absolute maximum — is the one that ends the session.