Sessions
Idle timeout and absolute expiry
Two different session limits: one measured from last activity, one from sign-in.
What Idle timeout and absolute expiry means
An idle timeout ends a session after a period without activity. An absolute expiry ends it a fixed time after sign-in regardless of activity. They defend against different things and a system with only one has a gap.
How it works
Idle timeout defends the unattended device — the browser left open on a shared workstation. Its weakness is that continuous activity extends it forever, so a compromised session that keeps making requests is never closed by it.
Absolute expiry defends against exactly that. Whatever happens, the session ends and the user re-authenticates. Its weakness is that it interrupts legitimate long work, which is why the window is usually generous.
The right values are not universal. A clinical system on a shared terminal and an internal tool used by five engineers have genuinely different answers, which is why this belongs to the tenant rather than to the product.
The mistake people actually make
Setting an idle timeout and calling it a session limit. A session that renews on every request has no maximum life, and a stolen session that stays busy never ages out.
In Authreads
How this applies here
Both are per-tenant policy: a tenant sets its own idle timeout and absolute expiry rather than inheriting a product-wide default.
Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.