Security Hardening: Explicit Session Expiry for Compliance Platforms (SEC-18)

Release: v0.1.139
Security Control: SEC-18
Affected File: src/lib/auth.ts

---

Background

The platform uses NextAuth with a JWT session strategy. Prior to this release, the NextAuth configuration in src/lib/auth.ts did not set an explicit session.maxAge value.

When maxAge is omitted, NextAuth silently falls back to its built-in default of 2,592,000 seconds — 30 days. For a general web application this may be acceptable, but for a sanctions screening platform used by UK compliance teams and subject to regulatory oversight, a 30-day unattended session window presents an unacceptable risk:

• A stolen or abandoned session token remains valid for up to a month.
• No explicit policy is recorded in code or configuration, making audits harder.
• Session lifetime was never a deliberate product decision — it was an implicit framework default.

---

What Changed

The session block in src/lib/auth.ts now reads:

session: {
  strategy: 'jwt',
  maxAge: 28800, // 8 hours — SEC-18 compliance
}

Why 8 Hours?

Eight hours maps to a standard working day. A compliance analyst who authenticates at the start of their shift will be required to re-authenticate by the following morning. This balances security with usability without disrupting active sessions during normal working hours.

If your organisation's security policy mandates a shorter or longer window, update maxAge accordingly and re-document the rationale in the same file.

---

Impact on Users

Scenario	Before	After
Session lifetime	Up to 30 days (implicit)	8 hours (explicit)
Re-authentication frequency	Monthly (at most)	Daily (start of each working day)
Abandoned session exposure window	30 days	8 hours

Users who leave a browser tab open overnight will be prompted to sign in again the next morning. This is expected and intentional behaviour.

---

Recommended Follow-up Actions

This release closes the explicit session lifetime gap. The following items remain open for future consideration:

1. Session rotation on privilege changes — When a user's role is elevated or their password is changed, the existing session token should be invalidated and a new one issued. This prevents privilege escalation attacks using a captured token.
2. Role-specific session windows — High-privilege administrator accounts may warrant a shorter maxAge (e.g. 4 hours) compared to read-only analyst accounts.
3. Idle timeout — maxAge controls the absolute session lifetime. A separate idle/inactivity timeout (client-side or server-side) should be considered for terminals that are left unattended.

---

Configuration Reference

// src/lib/auth.ts
export const authOptions: NextAuthOptions = {
  // ... providers, callbacks, etc.
  session: {
    strategy: 'jwt',
    maxAge: 28800, // seconds — 8 hours
  },
};

To change the session lifetime, update maxAge (in seconds) and commit the change with a note referencing your organisation's session management policy.

---

This change was introduced under security control SEC-18 as part of the platform's ongoing compliance hardening programme.