While researching session based authorization methods, I’ve been comparing server side against JWT-based approaches. Server side sessions appeals to me because it allows immediate access revocation. However, I’ve noticed a potential security concern with rolling session expiration. When rolling sessions, the expiration time updates on every request (at least this is how it’s implemented with express-session where all my questions started). This means if an attacker steals a session ID, they could maintain access indefinitely by making regular requests that keep extending the session’s lifetime (at least until the session is explicitly deleted/logged out). I tried to research more about this but couldn’t find much other than sessions could be fingerprinted with info like user-agent to add extra security.

This made me wonder: Why don’t session-based systems implement a refresh mechanism similar to JWT’s access/refresh token pattern? Such a system could use:

1. A primary session ID for normal requests (with short expiration)
2. A separate session refresh ID (with longer expiration) that only gets used when extending the session

Both the session ID and session refresh ID would remain opaque tokens that would be queried and verified on the server.

This approach would improve security since an attacker who steals just the session ID couldn’t extend access indefinitely without also having the refresh token, which is exposed less frequently.

So why is using a separate refresh token for server side session based authorization not more common as it is with JWTs?