CepatEdge

Appearance

Token Lifecycle & Revocation Model (Design) ​

This document defines how CepatEdge should handle token lifetimes and revocation in an institutional deployment. It is the target model; implementation should converge on this.

1. Token Types and TTLs ​

We use two main token types inside CepatEdge (separate from IdP tokens):

  • Access token (JWT)

    • Purpose: authorize API requests.
    • TTL: 15 minutes.
    • Stored in: HttpOnly cookie or in-memory (never in localStorage).
    • Validation: signature, issuer, audience, expiry, session/version check in Neon.

  • Refresh token

    • Purpose: obtain new access tokens without re-authenticating at IdP every time.
    • TTL: 7 days (institution can request shorter/longer).
    • Stored in: HttpOnly cookie (server-side identifier only).
    • Persisted in: Neon sessions table (or equivalent) with status and metadata.

Institutional IdP tokens (OIDC ID/access tokens) follow the IdP’s own TTLs and policies; we do not override those, we respect them.

2. Where Revocation State Lives ​

Revocation information must be server-side and centralised so any Worker/DO can enforce it.

  • Primary store: Neon

    • sessions table with fields like:
      • session_id
      • user_id
      • revoked_at
      • expires_at
      • reason (optional)
    • Access tokens include a session identifier or version; Workers check this against Neon/cache.

  • Secondary cache (optional): Durable Object / in-memory cache

    • To avoid hitting Neon on every request, a DO or in-memory cache can store a small map of:
      • session_id → active | revoked | expired.
    • Cache entries have short TTLs and are invalidated when a session is revoked.

3. Revocation Triggers ​

Revocation happens on:

  • User-initiated logout (from SPA).
  • IdP-initiated events (account disabled, password reset, admin deprovision) – consumed via webhook or periodic sync.
  • Security events:
    • Suspicious activity (e.g. impossible travel, brute force).
    • Token theft / compromise.
  • Admin actions:
    • Force logout of a single user or all sessions for a user.

For each trigger, we:

  1. Mark the relevant session(s) as revoked in Neon.
  2. Invalidate any corresponding entries in DO/cache.
  3. On next request, access token fails the session/version check and is rejected.

4. Relationship to Security Docs ​

  • docs/security/overview.md should reference this document as the authoritative design for token lifetimes and revocation.
  • Any changes to TTLs or revocation flows must be reflected here first, then mirrored into security docs and implementation.