Long lasting user sessions

[sixers]

How do you recommend implementing long-lasting user sessions? So that they are not logged out. Typically, in the JWT implementations I've encountered, there are two tokens: a short-lived (minutes) access token that contains encoded user data, and a long-lived (days) opaque refresh token. I understand from the documentation that Payload only has the former. In that case, do you recommend simply setting a high value for tokenExpiration (e.g. a week)?

[jmikrut]

@sixers this is a great question! Thanks for opening up this discussion here because I bet this will be of value to a lot of people - and we're going to get a bit theoretical.

You're right that the typical "access / refresh" token is pretty standard. But it never made a whole lot of sense to us - because in web apps, if you store both as an httpOnly cookie, then theoretically if you hijack one, you hijack the other. Meaning... it's not much more secure than a long lasting access token on its own. Even if the access token is expired, an attacker can simply use the refresh token and boom. Get a new access token. Thus, in order for the refresh token to be secure, you need to take even more steps to keep them secure like "refresh token rotation". Complexity. We like things simple and secure.

Instead of following this pattern, what Payload has built out is a somewhat simpler refresh pattern. I am very interested in hearing thoughts about it.

Basically, we have the traditional login operation that returns an access token, which can be set to expire however long you need. The default expiration time is 20 minutes. It's not advisable to make this super long.... but we have a solution for this.

We have our own refresh operation.

This operation is simply an easy way to take a still valid token (no username or password required), and extend its lifetime. It can be very easily used by your applications, too. What we commonly do in our own apps is something like the following:

• We keep our token lifetime short
• If a user is active in an app of ours, every X minutes or so we go out and hit the refresh operation, giving the user a new token
• This could be triggered by frontend route changes, significantly throttled form interaction changes, etc.
• If a user becomes inactive, a few mins before the token expires, we display a modal that says "You are about to be logged out due to inactivity..."
• If they take no action, they are logged out, and sent to a logged out screen.

This pattern is simple, secure, expected, and straightforward. It also allows people to be logged in for however long they need, as long as they're active. And we feel like it's a more straightforward path vs. having to rotate refresh tokens.

What do you think?

[sixers]

I would like to allow users to be inactive for a few days, and still be logged in when they return after a few days. I run a wholesale ecommerce site, and usage is regular but sporadic (users visit the site at least once every 1-3 days). I'm worried that it might be annoying for them if they have to log in every time. Based on what you've written, I'm leaning towards setting the expiration time to 3 days, and refreshing it regularly when the user visits the site, so if they visit at least once every 3 days, they will still be logged in, and I will only "log them out" after 3 days of inactivity. But as you write - this is quite a long lifespan for JWT tokens, so I have doubts if this is a good choice and wonder if there are any alternatives.

[jmikrut]

I think the moral of my story is that all ways to keep a user logged in for that long are equally risky, at least in a web app environment. However, the risk of a long lasting token is quite small anyway with Payload's built-in CSRF protection and httpOnly cookies.

I think you would be fine for setting your lifetime to longer, as in your use case, it directly impacts your users' experience. In most of our own cases, we are OK with having a user log back in if they take off for a few hours. I say go for it!

[sixers]

Great, thanks!