Clarix
Authentication

Session Management

Cross-device session handling and security

Session Management

Clarix uses server-side sessions stored in PostgreSQL for maximum security and cross-device synchronization.

Session Architecture

Client (Web, iPad, Android)
    ↓ sends cookie with session_token
API (Next.js, Expo)
    ↓ validates token
PostgreSQL (session table)
    ↓ returns user data + org context
Response includes user, role, organization

Session Properties

PropertyDescription
idUnique session ID (UUID)
tokenRandom session token (stored in cookie)
userIdForeign key to user table
ipAddressClient IP at login time
userAgentBrowser/device identifier
createdAtLogin timestamp
updatedAtLast activity timestamp
expiresAtSession expiry (login time + 24 hours)
activeOrganizationIdCurrent org context

Cross-Device Sync

Sessions are shared across all platforms because they are validated server-side:

  1. Web (localhost:3000) — session cookie in browser
  2. iPad (React Native) — session token in secure storage
  3. Android (React Native) — session token in secure storage

When a user logs in on any device, the same session token works everywhere. Session refresh on any device extends expiry for all.

Session Lifecycle

Login → Session Created (24h TTL)

Activity → Session Updated (TTL extended every hour)

24h of inactivity or explicit logout → Session Destroyed

Security Controls

ControlImplementation
StorageServer-side only (PostgreSQL). No JWT.
TransportHTTPS-only cookie with HttpOnly, SameSite=lax
RotationToken rotated on refresh for added security
Concurrent limitConfigurable max sessions per user (default: unlimited)
Force logoutAdmin can invalidate any/all sessions for a user
Device trackingIP + user agent recorded per session

E-Signature Sessions

For operations requiring e-signatures (batch execution, formula approval), a secondary authentication factor is required:

PlatformFactor 1Factor 2
WebActive sessionPIN re-entry
iPadActive sessionPIN + FaceID/TouchID
AndroidActive sessionPIN + fingerprint

The e-signature creates a separate e_signature record linked to the action, not a new session.

On this page