We are currently using JSON web tokens for authentication for our website's API. We use 1 hour short-lived access tokens that get refreshed using a permanent revocable refresh token.
Now we want to add an account + login system to the website and tie it to the API usage. However, we are currently debating on the security of this.

The naive implementation would be just a 3 hour access token for a session and something like 2 weeks expire time if the user chooses the "stay logged in" option. However, this would kinda make the short expire time useless. In case the tokens get leaked you have an attack window of two entire weeks.
The alternative we thought of would be some kind of "proxy" that checks if the token is expired and refreshes automatically with the refresh token in localstorage or as a cookie.

Would the naive version be an acceptable implementation or are the security risks too high?

2 Answers 2


It depends on the requirements of the host and network that you're in .

As with any password an JWT/cookie or whatever it may be, the longer the item is available without change the more time a hacker has for it to be broken.

I personally have my JWTs secret generated with a random key upon the web application starting.

I set a life span on JWTs to be no longer than 5 hours. You can also look for other items in the cookie like OS, browser , IP address ect. It depends on how you want to handle it.

You can have all JWTs killed at the end of office hours too.

3 hour access token for a session and something like 2 weeks expire time if the user chooses the "stay logged in" option.However, this would kinda make the short expire time useless.

I agree. Encourage users to utilize lastpass or keypass might be an option. I personally thinking that logging in once every 5 hrs is not an inconvenience and is a cheap cost for doing business.

Let me know if this answers your question or helps.


I had similar concerns when looking at moving from stateful sessions to token-based authentication.

We wanted a scenario similar to the existing "20 minutes since last request" validity, so we settled on the following:

On login, we generate a token valid for 20 minutes and send it to the user. For subsequent requests, we validate that token and if more than 5 minutes have passed since it was created, we go ahead and create a new 20 minute token and send that to the user.

These tokens had 2 random secrets encrypted into them - one for the application, and one for the user (stored in the database alongside the user record). The application one was checked on every request, and the user one was checked whenever a token was due for renewal (so at most every 5 minutes).

If the user had any concerns they could either logout all sessions, or change their password. Both these actions would generate a new user secret, meaning that at most an old token would only be valid for 5 minutes. If there was a serious issue, we could change the application secret and immediately invalidate all existing tokens.

  • app and server secrets are a bit redundant here, you might as well change the hash key, thus invalidating all incoming tokens .
    – Stavm
    Feb 21, 2019 at 8:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .