SaaSKit Session Management

Guardrails

• MUST choose storage by app type (ask first — see Inputs):
  • Traditional / server-rendered web apps: store access and refresh tokens in HttpOnly cookies, with Secure enabled in production.
  • SPAs: keep the access token in memory (send via Authorization: Bearer); store the refresh token in an HttpOnly cookie or other secure storage — do not put the access token in localStorage.
  • Mobile: use secure platform storage for refresh; keep access tokens short-lived in memory when feasible.
• MUST validate the access token on every protected request and transparently refresh it via the refresh token when expired.
• MUST NOT let a failed refresh silently continue the request; return 401 and force re-login.
• MUST revoke the corresponding session via the Scalekit session API on logout / "sign out this device".

Inputs to collect (ask before coding)

• App type: traditional server-rendered web app, SPA, mobile app, or hybrid.
• Framework: Express/Fastify/Next (Node), Flask/Django/FastAPI (Python), Gin/Fiber (Go), Spring Boot (Java), etc.
• Token storage plan:
  • Cookie names (examples used below: accessToken, refreshToken, idToken).
  • Cookie attributes actually used in the repo (Path, Domain, Secure, HttpOnly, SameSite).
• Encryption approach already present (KMS, libsodium, AES-GCM, framework session store), or whether the app needs one introduced.
• Scalekit SDK/client availability and the exact methods used (validate, refresh, sessions list/revoke).