Session timeout policy (OWASP) — what should it be?

[unidoc-ahall]

Context

Session lifetime today is a single global value: jwtLifetime() defaults to
24h, overridable only via the ISMS_JWT_LIFETIME env var
(internal/isms/api/jwt.go). The JWT carries an absolute expiry — there is
no idle/inactivity timeout, so a token is valid for the full lifetime regardless
of activity. It is not configurable per organization.

ISMS is a governance product, so session management deserves an OWASP-informed
decision rather than a default that happened to be picked.

Questions to decide

1. Per-org configurable timeout? A regulated tenant may want a much shorter
   session than a relaxed one — with a safe ceiling?
2. Absolute vs idle timeout. OWASP recommends an inactivity (idle) timeout in
   addition to (or instead of) a fixed absolute expiry. Add an idle timeout?
3. Default value. Is 24h right for a governance product, or shorter (e.g. 8h)?
4. Re-auth for sensitive actions. Which actions should demand fresh
   authentication (pairs with disabling OTP, etc.)?

Notes

• Decision-first — let's settle the policy here before any code.
• It lands in a feature release (needs a schema change for the per-org setting).
• Reference: OWASP Session Management Cheat Sheet.

Input welcome — please weigh in.

[unidoc-ahall]

Important constraint: step-up auth must be auth-method-aware.

We must not impose ISMS-local TOTP on federated users — that breaks the flow for
Entra ID / OIDC shops and duplicates MFA they already have.

• OIDC / federated: step-up = re-trigger the OIDC flow with elevated
  assurance — prompt=login and/or max_age=0, request MFA via acr_values,
  verify amr. The IdP provides the second factor.
• Local accounts: step-up = re-enter password / TOTP locally.

Principle: delegate to the IdP where one exists; never stack ISMS 2FA on top of
federated identity. Keep the auth surface minimal.