How to deal with token expiration?

[soulmachine]

I think token expiration is a key feature that this project is lack of, here are some good discussions on Hacker News, https://news.ycombinator.com/item?id=8283006

[ghost]

Thanks Frank,

I agree. I just haven't gotten around to implementing it yet.

[soulmachine]

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 make a JWT token expire

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)

[skairamk]

first of all thanks for brahalla for this git repository. very easily understandable code.
thanks to soulmachine for very informative inputs on expiration and revoking of tokens.
one question - how to store the tokens safely in a native app in ios/android? I know, you said, its beyond this article. can you throw some light or refer my other articles. appreciate it. thank you

[ghost]

I don't know a ton about native mobile app development. A quick google search lead me to this Stack Overflow question.

Seems like for iOS you would store it in the keychain, which seems reasonable to me. For Android, looks like the KeyStore. If you're doing a hybrid app your guess is as good as mine... for anything using Cordova I would probably just put it in localstorage.

[liuyatao]

@soulmachine Your discussion helps me a lot,thanks.

[kamilwlf]

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

Is it already impplemented?
I created:
{
"sub": "[email protected]",
"audience": "mobile",
"created": 1496925372385,
"exp": 1497530172
}

and still after 1 week my token is expired

claims = Jwts.parser()
always throws claims = Jwts.parser()

@throws ExpiredJwtException if the specified JWT is a Claims JWT and the Claims has an expiration time
* before the time this method is invoked.
* @throws IllegalArgumentException if the {@code claimsJws} string is {@code null} or empty or only whitespace
* @see #parsePlaintextJwt(String)
* @see #parseClaimsJwt(String)
* @see #parsePlaintextJws(String)
* @see #parse(String, JwtHandler)
* @see #parse(String)
* @SInCE 0.2
*/
Jws parseClaimsJws(String claimsJws)