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.
- 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.
- 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.
- 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.