10

Reading about JWT I see it is common practice to include a refresh token along with the short lived token. So commonly it seems you have a short lived token which lasts for a short time such as 15 minutes, and a refresh token which renews this token when it is expired. From my understanding if the short lived token has expired the app must check to make sure the refresh token has not been revoked (check database). If it has not, then issue a new short lived token. I am trying to understand why not just have a single short lived token.

Lets assume the jwt token contains the username of the user using the token and expires in 1 hour. When it expires, can't my application server verify this token to make sure it is actually expired and it has been issued by me, if so check (inside of database) that this user can have their token renewed and renew it. Is this not essentially the same as having a refresh token, but it is a little simpler as I the user only has 1 token instead of 2? I cannot see the advantage of having a refresh token?

user2924127
  • 877
  • 1
  • 8
  • 17
  • 2
    If the token has expired it is no longer valid. Why would you issue a new token to a user that presented you an expired one? Verifying an expired token and accepting it and then issuing a new one destroys the purpose of short-lived tokens. Presenting an expired token should result in having to re-login. One technique that you can use instead of a refresh is if a token presented to you only has, say 5min left, issue a new one. If it expires you make them re-login. This technique can also be very RESTful if used with JWT since you aren't storing any session. – dylan7 Mar 08 '16 at 07:42

1 Answers1

8

I'm assuming you are using some proprietary authentication solution, which is using JWT and refresh tokens but has nothing to do with OpenID Connect.

JWT tokens are stateless, refresh tokens are usually statefull.

You should look at advantages and disadvantages of statefull vs stateless tokens:

  • Stateless tokens can be validated without extra DB/Service call (so they are faster/easier to validate) but it is impossible to revoke them (no reliable logout).
  • Statefull tokens may be revoked (reliable logout) but they must be validated via DB/Service call each time (so they are slower).

Long-lived JWT tokens would constitute an increased security risk - attack window would be long if token is stolen.

In combination with refresh tokens, you get the solution somewhere in the middle: Validation is fast and logout is more reliable.

Depending on where which token is used (client vs server), you could implement automatic refresh. However, for such proprietary solution, you could indeed use a single token with a validation cache if necessary due to performance reasons.

Vilmantas Baranauskas
  • 206
  • 1
  • 2
  • Why is there the assumption that an attacker would somehow have access to the access token but not the refresh token (and so they can refresh whenever they want)? – hytromo Jun 25 '19 at 15:02
  • There is no such assumption. You can pro-actively revoke stateful tokens, for example by clicking "Logout". In case an attacker got access to refresh token, it would become useless instantly. Stateless tokens cannot be revoked pro-actively. – Vilmantas Baranauskas Jun 25 '19 at 15:20
  • 1
    Sorry, I asked with OP's question in mind. What I mean is "Why have refresh tokens and not make the simple JWTs stateful"? To simply avoid db calls in every request and do db calls once the token is to be refreshed? – hytromo Jun 26 '19 at 17:26