Configure how Auth0 manages user sessions in your Next.js application. The SDK provides flexible session configuration options including rolling sessions, custom timeouts, and database storage.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/auth0/nextjs-auth0/llms.txt
Use this file to discover all available pages before exploring further.
Basic Configuration
Configure session settings when initializing the Auth0 client:lib/auth0.ts
Configuration Options
| Option | Type | Default | Description |
|---|---|---|---|
rolling | boolean | true | Enable rolling sessions (extends on activity) |
absoluteDuration | number | 259200 (3 days) | Maximum session lifetime in seconds |
inactivityDuration | number | 86400 (1 day) | Inactivity timeout in seconds |
Rolling Sessions
Rolling sessions provide a seamless user experience by automatically extending session lifetime as users actively use your application.How Rolling Sessions Work
Active usage
Each request extends the session by
inactivityDuration as long as the session is within the inactivityDuration window.Enabling Rolling Sessions
Rolling sessions are enabled by default. To disable them:lib/auth0.ts
Middleware Requirement
Rolling sessions require the authentication middleware to run on all requests. ✅ Correct Configuration:middleware.ts
middleware.ts
- Session extension: Each page request extends the session lifetime
- Consistent auth state: Ensures authentication status is up-to-date across all pages
- Security headers: Applies no-cache headers to prevent caching of authenticated content
If you disable rolling sessions (
rolling: false), you can use a narrow middleware matcher since sessions don’t need to be extended on every request.Session Duration Examples
Short-lived sessions (1 hour)
Standard sessions (7 days)
Long-lived sessions (30 days)
Remember me functionality
Implement “remember me” by using different Auth0 client instances or by conditionally setting session options based on user preference.
Database Sessions
By default, user sessions are stored in encrypted cookies. For applications with large sessions or server-side session revocation requirements, you can store sessions in a database.Implementing Database Sessions
Session Store Methods
| Method | Parameters | Description |
|---|---|---|
get(id) | id: string | Retrieve session by ID |
set(id, sessionData) | id: string, sessionData: SessionData | Store or update session |
delete(id) | id: string | Delete session by ID |
deleteByLogoutToken({ sid, sub }) | sid?: string, sub?: string | Delete sessions for Back-Channel Logout |
Database Schema Example
Prisma:schema.prisma
Cleanup Expired Sessions
Regularly clean up expired sessions to prevent database bloat:lib/cleanup-sessions.ts
Cookie-Based Sessions (Default)
By default, sessions are stored in encrypted HTTP-only cookies. Advantages:- No database required
- Fast (no database queries)
- Stateless (scales horizontally)
- Built-in encryption
- 4KB size limit (browser cookie limit)
- Cannot revoke sessions server-side
- All session data sent with every request
Cookie-based sessions are recommended for most applications. Use database sessions only when you need server-side session revocation or have large session data.
Best Practices
- Use rolling sessions for better user experience
- Set appropriate timeouts based on your security requirements
- Use broad middleware matcher to ensure rolling sessions work correctly
- Clean up database sessions regularly if using database storage
- Monitor session size to stay within cookie limits (4KB)
- Test session expiration to ensure users are logged out as expected
Troubleshooting
Sessions expiring too quickly
If sessions expire faster than expected:- Check
inactivityDurationis set correctly - Verify middleware is running on all requests
- Ensure
rolling: trueis set - Check for clock skew between servers
Sessions not extending
If sessions aren’t being extended with activity:- Verify middleware matcher includes all routes
- Check that
rolling: trueis set - Ensure requests are hitting the middleware
- Look for errors in middleware execution
Cookie size limit exceeded
If you see cookie errors:- Reduce session data size (remove unnecessary fields)
- Use database sessions instead of cookie storage
- Compress session data before storing
- Store large data in database, keep only references in session
Database sessions not persisting
If database sessions aren’t working:- Verify database connection is working
- Check session store implementation
- Ensure database schema is correct
- Look for errors in session store methods