Skip to main content
The SDK supports two session storage strategies: stateless (cookie-based) and stateful (database-backed).

Session Store Types

Stateless Sessions (Default)

Session data is encrypted and stored in cookies. No external storage required. Advantages:
  • No database dependency
  • Simple setup
  • Serverless-friendly
Limitations:
  • Cookie size limit (~4KB)
  • Cannot revoke sessions server-side
  • Not suitable for large sessions

Stateful Sessions

Session data is stored in an external database. Cookies only contain a session ID. Advantages:
  • No cookie size limits
  • Server-side session revocation
  • Better for large sessions with multiple tokens
Limitations:
  • Requires database setup
  • Additional latency for database queries

Default Configuration

By default, the SDK uses stateless sessions:
lib/auth0.ts

Implementing Stateful Sessions

SessionDataStore Interface

Implement the SessionDataStore interface to create a custom session store:

Redis Example

lib/redis-store.ts

PostgreSQL Example

lib/postgres-store.ts

MongoDB Example

lib/mongo-store.ts

DynamoDB Example

lib/dynamodb-store.ts

Configuring the Session Store

Provide your custom store to the Auth0Client constructor:
lib/auth0.ts

Session Configuration

Configure session behavior regardless of storage type:
boolean
default:true
Enable rolling sessions. When enabled, the session is extended on each request.
number
default:259200
Absolute session lifetime in seconds (default: 3 days).
number
default:86400
Inactivity timeout in seconds (default: 1 day).
Cookie configuration options:
For stateless sessions, the entire session is stored in the cookie. For stateful sessions, only the session ID is stored.

Environment Variables

Cookie options can also be configured via environment variables:

Session Lifecycle

Session Creation

Sessions are created after successful authentication:
  1. User completes authentication
  2. SDK receives tokens from Auth0
  3. Session is created with:
    • User profile
    • Token set (access, ID, refresh)
    • Internal metadata (creation timestamp)
  4. Session is stored:
    • Stateless: Encrypted in cookie
    • Stateful: Stored in database, ID in cookie

Session Updates

Sessions are updated when:
  • Tokens are refreshed via getAccessToken()
  • Session data is modified via updateSession()
  • Rolling sessions extend on each request

Session Expiration

Sessions expire based on:
  1. Absolute Duration: Maximum lifetime from creation
  2. Inactivity Duration: Maximum time without activity
The earlier of these two determines expiration.

Session Deletion

Sessions are deleted when:
  • User logs out via /auth/logout
  • Session expires
  • delete() is called on the session store

Session Store Comparison

Best Practices

Use stateless sessions for most applications. They’re simple, fast, and serverless-friendly.
Use stateful sessions when:
  • Sessions exceed 4KB (many MRRT tokens)
  • Server-side revocation is required
  • You need to track active sessions
Implement session cleanup in your database to prevent orphaned sessions:
Secure your session store. Use encrypted connections and restrict access to the session database.

Session Security

Encryption

  • Stateless: All session data is encrypted with AUTH0_SECRET
  • Stateful: Session ID is encrypted, store data as needed

Session Fixation Prevention

When using stateful sessions, the SDK automatically:
  • Regenerates session IDs on login
  • Deletes old sessions

getSession

Retrieve session data

updateSession

Update session data