Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
How to deal with JWT expiration?

First of all, please note that token expiration and revoking are two different things.

  1. Expiration only happens for web apps, not for native mobile apps, because native apps never expire.
  2. Revoking only happens when (1) uses click the logout button on the website or native Apps;(2) users reset their passwords; (3) users revoke their tokens explicitly in the administration panel.

1. How to hadle JWT expiration

A JWT token that never expires is dangerous if the token is stolen then someone can always access the user's data.

Quoted from JWT RFC:

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.

So the answer is obvious, set the expiration date in the exp claim and reject the token on the server side if the date in the exp claim is before the current date.

Quite easy, huh?

The problem is that mobile apps never expire, for example, people can reopen the APP after a month without the need to login again.

  1. For Web Apps: If you set the expiration time to 1 week, do not use the token for 1 week. Use it less than a week and get a new token before the old token expires. For example, make the browser send out a request to exchange for a new token at the sixth day. This is not different than the normal concept of session and cookies.

    Accordingly, on the server side, create a restful API named /token/extend which will return a new token if given a valid token.

    If the user does not use your application for a week, next time he goes to your app, he will have to login again and this is fine and widely accepted.

  2. For native mobile Apps: you can use the same explained above, but that's not how mobile Apps work nowadays, e.g., an user can open the Facebook App after a month not using it and next time when he open the App he doesn't need to login again.

    One solution is to add an audience claim named aud to JWT tokens, for example, use the payload like {"sub": "username", "exp": "2015-11-18T18:25:43.511Z", "aud":"iPhone-App"}. On the server side if the token has an aud field that has the value iPhone-App then ignore the exp claim, so that tokens with iPhone-App never expire. However, you can still revoke this kind of tokens by using the methods described in Section 2.

    Another solution is to use a refresh token that never expires to fetch a new JWT token that does expire. Since the refresh token never expires, what happens if your phone is stolen? Again, refresh tokens are still valid JWT token, you can revoke refresh tokens using the methods described in Section 2.

    Normally to distinguish with different refresh tokens of one user, a good practice is to put the specific device name into the refresh token, for example, {"sub": "username", "exp": "2015-11-18T18:25:43.511Z", "device":"Frank's iPhone"}, so that when a user wants to revoke refresh tokens, he can know this refresh token is being used on his iPhone.

2. How to revoke a JWT token

Sometimes users need to revoke a token, for example, clicking the logout button, or changing the password.

Assume that each user has multiple devices, let's say, a browser, a native iPhone APP, and a native Android APP.

There are three ways:

  1. Changing the secret key.

    This will revoke all tokens of all users, which is not acceptable.

  2. Make each user has his own secret and just change the secret of a specified user.

    Now the RESTful backend is not stateless anymore. Every time a request comes in the server needs to query the database to get the secret of a user.

    To get better performance let's store the (user, secret) pairs in Redis instead of MySQL, use the username as the key and the secret as the value.

    This way will revoke all tokens of one user, much better, but still not good enough.

  3. Store the revoked JWT tokens in Redis.

    Use the token as the key and the value is always a boolean true.

    The token will be stored only for a specific amount of time, which is the time in the exp claim, after the expiration time it will be deleted from Redis.

    This way only revokes just one token at a time, perfect!

    For more details please refer to this blog, Use Redis to revoke Tokens generated from jsonwebtoken

Suggestions are welcomed, please correct me if I'm wrong.

3. How to use JWT tokens securely

First, always use HTTPS to make sure JWT tokens transmission over network is safe. By using HTTPS nobody can sniff users' JWT tokens over network.

Second, make sure JWT tokens are stored securely on users' Android, iOS and browser.

  • For Android, store tokens in KeyStore
  • For iOS, store tokens in KeyChain
  • For browsers, use HttpOnly and Secure cookies. cookie. The HttpOnly flag protects the cookies from being accessed by JavaScript and prevents XSS attack. The Secure flag will only allow cookies to be sent to servers over HTTPS connection.

As long as we make the browsers, user devices and tokens transmission safe, token revocation mechanism is not necessary anymore.We can still keep our RESTful services stateless.

Reference

  1. RFC 7519 - JSON Web Token (JWT)
  2. Use Redis to revoke Tokens generated from jsonwebtoken
  3. I don’t see the point in Revoking or Blacklisting JWT
  4. JSON Web Tokens | Hacker News
  5. Blacklisting JSON Web Token API Keys
  6. Token Based Authentication for Single Page Apps (SPAs)
@zakisaad

This comment has been minimized.

Copy link

commented Aug 30, 2018

On point 2.3 -

If you delete the token from Redis after the exp, then aud will be able to log in again (even if the JWT was issued with a different password, etc.)

@weidenhaus

This comment has been minimized.

Copy link

commented Feb 5, 2019

Very helpful, thank you!

@ibrahimsn98

This comment has been minimized.

Copy link

commented Feb 8, 2019

Thank you!!

@BumpeiShimada

This comment has been minimized.

Copy link

commented Feb 26, 2019

Thank you!

@hansaliyad1

This comment has been minimized.

Copy link

commented Feb 27, 2019

I have a question here on your point "make the browser send out a request to exchange for a new token at the sixth day. Accordingly, on the server side, create a restful API named /token/extend which will return a new token if given a valid token."

Let's assume that I implement this concept. When token is about to expire, we will generate new valid token if old valid token is provided.

Now, let's assume, Hacker gets the token. He uses this token to communicate with APIs. Hacker communicates for 6 days. On 6th day, our "/token/extend" API will generate new token for him so he can communicate for another 6 days, and probably forever. Will this situation occur? or Am I missing something here?

@symbioticstar

This comment has been minimized.

Copy link

commented Mar 5, 2019

On point 2.2
Why storing in redis is still not good enough?
I think it will store less in redis than 3.3.

@michaellee8

This comment has been minimized.

Copy link

commented Mar 9, 2019

Useful, but I doubt if the reissue one is good. I prefer user re login the app than issuing a token to them repeatedly.

@jetamartin

This comment has been minimized.

Copy link

commented May 2, 2019

I'm not sure what is meant by:
"The problem is that mobile apps never expire, for example, people can reopen the APP after a month without the need to login again."

When the user launches the Mobile App wouldn't you just connect with server as part of the start up process for the app and check to see if there is a valid/non-expired token on the server for that device. If the token has expired just require that the user login.

What am I missing here?

Cheers.

@jkeam

This comment has been minimized.

Copy link

commented May 3, 2019

@jetamartin I read that as an awkwardly written sentence. So

"The problem is that mobile apps never expire, for example, people can reopen the APP after a month without the need to login again."

In my head I read that sentence as:

"The problem with mobile apps is that the user's expectations is that they should never be logged out. So for example, a person can re-open the mobile app a month later and their expectation is that they should not need to log in again."

@ardyfeb

This comment has been minimized.

Copy link

commented May 25, 2019

In my implementation, on apps i will set expires token too then i save username / password on secure store. when token expired just authenticate it self

@Denisiuk

This comment has been minimized.

Copy link

commented Jun 4, 2019

Almost everything is wrong. Please, check out other docs.
https://tools.ietf.org/html/rfc7519

@Xeoncross

This comment has been minimized.

Copy link

commented Jul 9, 2019

  1. Store the revoked JWT tokens in Redis

How would you know what JWT tokens were revoked unless you had already stored all of the tokens for each user?

@BertCatsburg

This comment has been minimized.

Copy link

commented Jul 12, 2019

If you state the problem as: "I'm on the server and I have no way of forcing users to log in again with tokens which had no expiry date."

Then there is IMO an easy solution for that: Just add a 'forceLogin' to the Payload and change the value of that. Then the next time the token is used by the user an error will occur and the Client (Mobile or Web) will redirect the user to the Login page.

const token = jwt.sign( { email: user.email, userId: user._id, forceLogin: user.forceLogin } )
The forceLogin field on the User record has a dummy value ("never" sounds nice). Just change that value to something else.

@jacobtylerdavis

This comment has been minimized.

Copy link

commented Jul 18, 2019

@hansaliyad1 Yeah that's right, the hacker would be able to exchange the token for a new one indefinitely. The benefit being that the tokens go stale, so an old token wouldn't be useful. What that said, most tokens are stolen directly from the browser (XXS) or from the request (lack of using encryption/https) and generally aren't sitting on a hard disk or database. Thus, token storage and transmission (HttpOnly, and Secure flags on web, KeyChain on devices) are extremely important.

@angelxmoreno

This comment has been minimized.

Copy link

commented Aug 21, 2019

Now the RESTful backend is not stateless anymore. Every time a request comes in the server needs to query the database to get the secret of a user.

Are you implying that if every request that comes in needs to query a database, that the backend is no longer stateless?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.