Keeping sessions alive longer

[starbelly]

Currently and per wildapricot as the oauth provider, the max ttl time on a session is extremely short (15 minutes). This issue has been created to go over ideas of how we might be able to extend sessions securely.

Currently, if you make requests within that ttl you, we refresh with wildapricot, and extend the session. However, if you say don't do anything for 16 minutes, then perform a request, you will be logged out. Since we don't deal in PII data directly or anything sensitive, it doesn't make sense for our app IMO.

The first idea that comes to mind is creating a GenServer that holds sessions on the backend and periodically will refresh them. Let's say the user has exceeded 15 minutes, let's say they make their next request 1 minute after said 15 minute window , but we have refreshed on the backend. We could lookup the session on the backend and merge the expiration, etc. in the session data and update the cookie.

Obviously, there would need to be an upper bounds on how many times we will do a refresh on the backend. The question at hand are there any security considerations that aren't being thought about with such a solution?

Pinging @voltone for his expertise in this area.

[voltone]

Why worry about the wildapricot token expiry once you've fetched the user details? You can just fetch the user information once, upon completion of the sign-in flow, then maintain a session with the user independent of wildapricot. That's how OIDC works, and I'm sure it's what Wordpress plugins etc. do when integrating with wildapricot. They do call their OAuth server an "SSO" service, after all: I don't think they intended it as a hosted session management solution.

Of course the session needs to follow best practices, in particular it needs to involve some server-side state that can be cleared on sign-out or after maximum session duration (or inactivity). That server side state could be stored in a GenServer or ETS, but I would stick it in the DB.

[starbelly]

@voltone sorry, I pinged you and then I'm quite late to respond. Yeah, we currently operate the way you described above exactly. We of course follow best practices, keep the session in the db, etc.

I suppose we could not depend on the ttl of the token, and instead simply query wildapricot to make sure the user making a request isn't deactivated, has had their role changed, etc.

Edit:

Note that the ttl currently is in line with best practices for low risk apps (15 to 30 minutes). We could increase to 30 minutes. I've always followed (or tried to) these recommendations and usually to the annoyance of others :) However, it makes for a bad UX. If it takes you say over 30 minutes to type something up and click submit, well... you're not going to be happy. Do you feel the owasp recommendation for low risk apps is a bit much?