Which JWT Refresh Strategy is safer?

Question

The basic idea is that the user session should be long and be continued/disabled based on user activity. However, as we couldn’t revoke token so the token should be short-term such as 15 mins. If we can refresh the token after it’s expired then the user session could be continued.

After some research, I found there are two implementations for this purpose:

1. JWT token with two TTL.

One for refresh expiration, one for token expiration. The refresh TTL is longer than token expiration TTL. The client will call server refresh api if it found current token is expired but still could be refreshed. The new token will have new expiration time and refresh expiration time. If both TTL expired, then that token is invalid and user is required to do authentication again. Pros * Requires No additional auth server. * The data of token could be modified so it can replace session under particular situations. Cons * The refresh token couldn’t be revoked.

2. Two token, one refresh token hold by auth server, one access token for access to application.

The refresh token is long-live, one week for example. The access token(JWT could be used here) is short-live, 15 mins for example. The client holds both tokens, every time it found access token expired(could be read from the payload of access token), it goes to auth server with refresh token asking for a new access token.

Pros

• Refresh token could be revoked as it’s stored in auth server.

Cons

• Requires additional auth server.

Questions

Let’s assume that in option 1, the token expiration time is 15 mins, and the time gap between token expiration and refresh expiration is also 15 mins. In option 2, the access token expiration time is 15 mins, and the refresh token expiration is one week.

Normal user

Keep using application

• Both options can refresh token well, the user experiences are the same.

Logout

• Option 1: Token is still valid. After at most 30 mins, the token become invalid.
• Option 2: Revoke refresh token immediately. access token is still usable for at most 15 mins.

Close browser without logout.

• Option 1: Token became invalid after at most 30 mins.
• Option 2: Refresh token is still valid for at most one week. Of course it can record when the refresh token is used as last activity to shorten this time window.

Malicious user (Try to stole every token)

Logout

• Option 1: Try to access refresh API, so that the token is kept be refreshed and usable.
• Option 2: Refresh token is dismissed. access token is still usable for at most 15 mins.

Close browser without logout.

• Option 1: Try to access refresh API, so that the token is kept be refreshed and usable.
• Option 2: Try to access auth server with refresh token, so access token is keeping generated.

My question is, is option 2 more secure than option1?

Our product is currently using distributing session just for storing user info. We wants to eliminate the use of auth server and session but security is our first priority. I didn’t see much advantages of option 2.

Am I misunderstanding something or any better token control strategy I missed? Any advices would be greatly appreciated.

Answer 1

The only point of having a refresh token is to allow user sessions to be renewed, without having users enter their password again.

Let's split a few uses cases

Short Lived Sessions in highly Sensitive Applications

Consider a session in a banking website, a payment site, or a public cloud (an AWS admin token could delete all a company infra).

• extremely sensitive information.
• sessions are purposefully limited to a very short time (5 minutes to 1 hour).
• the user has to login again with password (and 2FA) upon expiry. renewal is not supported.
• sessions may be longer (12h = a work day) for business applications (like AWS), to avoid employees having to authenticate constantly through the day.
• personal tip: don't bother much about invalidation (or lack thereof), tokens would expire long before you can realize they've been stolen/leaked and do anything about it. if anything shoulder surfing is a much bigger problem when forcing user to re-login every 15 minutes.

For this use-case, it must not be possible for sessions to be extended without user authenticating again, so there is no point in refresh tokens. Deliver short lived access tokens and don't deliver refresh tokens at all (they can be disabled in the OIDC provider).

Extremely Long Lived Session for mobile applications

Consider a session in a mobile application, could be a game, could be an app (facebook).

• no sensitive information (one might consider their facebook sensitive, but it's nothing like a gmail or a bank)
• sessions could last for a while. (did you ever have to authenticate again on facebook or tinder?)
• it's a huge PITA to (re)enter your password on a mobile. (a percentage of users won't come back when they have to. they often can't remember or don't want the hassle).
• mobiles are relatively safe. even if stolen, the thief typically can't unlock the screen or access the storage of the device/apps.

For this use-case, it would be nice to have sessions that can live very long but then it's important to be able to cancel them (device lost or stolen). Deliver access tokens for a day and deliver refresh tokens for 3 months.

When the application is opened, it can request a new session with the refresh token then work with it. It's possible to revoke a device access by invalidating the refresh token (see the "my active devices" in facebook/gmail for example).

Only minor downside is the user has to authenticate again if the application isn't used for months, which is reasonable in my opinion. (marketing/growth departments view may differ and they will probably ask to make it longer -how about infinite?-. better not make it longer than a year).

I am focusing on mobile applications here but web sites can be similar to some extent. The difference is that (browser) cookies on a laptop/desktop are extremely easy to extract, notwithstanding end-users having a ton of malware/adware potentially siphoning them out. So the environment is not quite as trustworthy, which is a concern for storing long lived tokens.

Transparent SSO and Renewal Sessions in Intranet

• TODO: add this tomorrow. already took more than half an hour to write so far