Hi all, we've been evaluating Supertokens as well, we were researching the flow and session management and had a question around session extension. Are there accommodations for usage-based session extension, for example, from a public machine? We have a heavy use case on public machines, our existing system uses a 'short-medium term lived access token whose usage extends their expiry' type of session management. Additionally, we have a mobile use case (and additional cases in the future) that fits perfectly with the 'suggested flow' (which is why we're evaluating Supertokens in the first place). We'd like to utilize the suggested Supertokens flow, but with the ability to extend a short-term session based on usage. We were wondering if this was a use case and if there were recommendations around this type of behavior

hey @User > usage-based session extension, for example, from a public machine? How do you define a public machine? How is it different than a browser session? > ability to extend a short-term session based on usage Our sessions expiry is based on usage. If the session's expiry is 100 days, it will expire only after 100 days of inactivity. If this is not the behaviour that is required, you can always use our override function on the backend to customise how this works. I can add more detail once you explain what is requied.

Ah yes, here we define public machine as shared computers. So user should have access to their information during their browser session, but session should not reactivate from refresh token if user is inactive for, say, 30 minutes. We'll review the code and see how the Session management works. So far our main reference has been: https://supertokens.com/blog/the-best-way-to-securely-manage-user-sessions, where it suggests session management technically has a fixed time (access token with a fixed expiry that can be refreshed from a refresh token with a long term, but still fixed expiry). But if the session management (perhaps built off the OAuth flow?) is based on usage then that's closer to our required behavior

hey @User yes. So the session management expiry is based on usage. For example in here, if you set the access token lifetime to some value < 30 mins and the refresh token's lifetime to 30 mins, then the session will expire after 30 mins of inactivity.

Oh! Of course. Dunno why my head was stuck in thinking that refresh expiry wouldn't reset when a new one was created. I think this flow accomplishes what we need then, I'll have to go through our flows and confirm

Sounds good!