From my understanding, the current standard when using JWTs for user sessions is to have a short-lived (expires after maybe 15 minutes) access token and a long-lived refresh token (expires after 24+ hours) which can be used to obtain more access tokens.

There seems to be a handful of reasons for this, the main ones being:

  • To decrease server load regarding authentication and session management.
  • To prevent an attacker from having long term access if they somehow obtain an access token.
  • To prevent new access tokens by revoking refresh tokens.

My concerns are:

  • Why do people think 15 minutes is short enough to prevent an attacker from doing whatever they want? A lot of damage can be done in 15 minutes.
  • If an attacker can obtain an access token, then they can most likely obtain a refresh token as well. This would allow them to obtain any as many access tokens as they need (until someone figures out that the refresh token has been compromised).

Am I missing something here? Or are JWTs not really meant for security? Are they really only meant to decrease server load?

  • Does this answer your question? How to handle refresh tokens
    – Josef
    Commented Aug 18, 2020 at 14:42
  • @JosefsaysReinstateMonica Not really. I'm aware of how access and refresh tokens are handled and how they work. My question is more about how secure JWT really is, and what can be done to maximize security. It seems everything I read talks more about the tradeoffs of the approach and how JWTs are good for reducing server load, not security.
    – loh
    Commented Aug 18, 2020 at 15:23

1 Answer 1


Access and Refresh Tokens (which aren't always JWTs) provide an additional layer of security and usually related to access.

As for your concerns, the expiry is not a sole defense against an attacker. You still need to enforce encrypted communication and secure storage of the tokens.

That is, if you have an attacker who gained access to your system in away that they can read your credentials, it's game over. No matter what kind of tokens you use. Even 5 seconds are plenty of time for a scripted attack.

The expiry serves two purposes:

  • It forces the system to re-interact with the identity and access management. This allows you to invalidate not-yet-expired Tokens from the Server Side (for example, if the User changes their password or clickt an Sign-me-out-everywhere button).

  • And it ensure that if you forget to explicitly invalidate them, they expire automatically.

A setup with Access and Refresh Tokens, as for example defined by the OAuth 2.0 Framework, provides additional security if implemented correctly.

You only need your Username and Password on an explicit login. Your client software (App or Browser) should never store these, as they are the keys to the kingdom. For example, your Google Username and Password allows you to access Mail, Calendar, Dokuments, App Store and all other Services provided by Google.

Access and Refresh tokens, on the other hand, can be scoped: they give you only access to a subset of the services you can normally access. An Access Token could be limited to use with email. If an attacker gained access to that token, they still can't access your Calendar, for example.

JWTs on the other hand are usually used as an Id Token, where you want to get more information on the user accessing the resource. Have a look at the documentation on the Auth0 Website on Tokens. The differences of the tokens are subtle.

  • Additionally the expiration times are mainly for “revoked access” use cases. (You revoke acces for user X but user X can still use the system for a max of 15 minutes) the same for when you elevate a user. JWT can convey much more than just simple authorization and authentication, like the grants of oAuth2/ openid connect. Further more JWT can be encrypted and cryptographically signed.
    – LvB
    Commented Sep 17, 2020 at 19:46

You must log in to answer this question.

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