Right now my session is expiring right after inactivityDuration: 30 * 60 (30 minutes). I want the session to automatically extend on user activity (e.g., API calls, page navigation) but still enforce an absolute max duration of 8 hours.
This is my current src/lib/auth0.ts config:
session: {
rolling: true, // extend session when server is hit
inactivityDuration: 30 * 60, // 30 minutes idle timeout
absoluteDuration: 8 * 60 * 60, // 8 hours hard cap
},
Is this the correct way to keep sessions alive based on user activity?
Do I need to configure anything else (middleware, API routes) to make sure “activity” extends the session correctly?
What’s the best practice to handle this in a large-scale production app?
Yes, your configuration is correct. The rolling: true setting in your auth0.ts file automatically extends a user’s session by the inactivityDuration (30 minutes) with every request, while the absoluteDuration (8 hours) acts as a hard cap. No extra middleware is needed for this to work. For a large-scale app, best practice also includes using secure server-side sessions and implementing a refresh token rotation strategy to handle the absolute duration expiration smoothly and securely without requiring users to log in again.
@Joshua855Hill Thanks for confirming. One thing I’m noticing though — when a session starts, my session cookie expiry is set to 30 minutes (same as my inactivityDuration). But it never seems to extend with activity. I’m getting logged out exactly after 30 minutes, even though rolling: true is enabled.
Is there something else I need to configure to make the session actually extend on user activity?
Have you followed our documentation here regarding implementing session extension on your application?
As far as our documentation mentions:
Middleware requirement: Rolling sessions require the authentication middleware to run on all requests. This is why the recommended middleware matcher is broad:
Let me know if that helps or if you have any other questions on the matter!
I’m working on implementing session timeout behavior in a Next.js app using @auth0/nextjs-auth0 v4.10. My requirements are:
Automatically log users out after 30 minutes of inactivity-
Show a warning modal 2–3 minutes before timeout with a “Stay signed in” option.
If the user clicks “Stay signed in,” extend the session up to the absolute duration (8 hours).
If no action is taken, expire the session and redirect to login.
I understand that in v4.10:
auth0.getAccessToken() (server-side API) checks the session, refreshes the access token if needed, and saves the session cookie (extending expiry if rolling sessions are enabled).
/auth/access-token (built-in SDK route) exposes the same functionality but as an HTTP endpoint, mainly for frontend use cases where the client needs a token.
My question is:
For the “keepalive” pattern that extends the session when the user clicks “Stay signed in,” should I rely on auth0.getAccessToken() in a custom /api/session/keepalive route (keeping token logic server-side), or is it equally recommended to just call /auth/access-token directly from the frontend?
I want to confirm the best-practice approach for security and maintainability in production.
What we implemented (rolling-specific)Session config:
rolling: true, inactivityDuration: 30m, absoluteDuration: 8h.
Middleware: we run auth0.middleware(req) on all non-asset requests and, on allow paths, we return the SDK’s response so any Set-Cookie is preserved and the session can roll.
Keepalive: a protected/api/ping that we call only on real user activity (throttled) and from a “Stay signed in” button.
Questions-
Please confirm: only responses produced by auth0.middleware(req) can extend the session; getSession() is read-only and does not roll.
Tenant vs SDK timeouts: should tenant session lifetimes be ≥ the SDK’s absoluteDuration/inactivityDuration to avoid earlier tenant-side expiry?