2

I have a koajs based nodejs backend for my personal/hobby app. I implemented session handling with jwt tokens. Now the client gets his token after a successful login authentication so my angularjs client stores the token somewhere (currently in sessionStorage but for this question we doesn't care about the storage). I have two questions

  1. When I need to update the user record which the jwt represents, say, the user turned on 2FA so I asked him to provide his phone number and I'd like to set this phone number in the user's record. Currently, after a successful verification on the phone number I call my backend to update the user record and I create a new JWT token with the updated user record (I exclude sensitive information from the jwt token like the hashed pwd and others.., but I'd like to include the phone number for client side usage). So, basically the question is, is it okay to create a new token when some of the credentials change and update the existing client side token with this new token? Should I never-ever create another token, only to create the one and only upon successful authentication? How to I update then the payload in the token?

  2. How should I handle expired jwt tokens? In my mind I have 3 (possible) scenarios:

    1. The jwt is set to short living, say 15minutes. If the backend server replies with a 401 Unauthenticated 'ivalid token' (I guess this is the default behavior of koa-jwt) then I automatically log-out my client and require re-authentication. But I also set up a complementary middleware which is the last in the chain on the backend to re-create the token with a refreshed expiry and the client would also replace the existing token with the refreshed one. So if the user is active and uses the application every protected api call, in case of success, would create a new token to replace the old token.

    2. The jwt is set long-living, say 1 week, and if it expires I opt-in re-authentication from the client.

    3. Copy https://tools.ietf.org/html/rfc6749#section-1.5. Here when creating the jwt token after a successful authentication we send an access_token as well as a refresh_token. When the access_token is expired and the server responds with HTTP 401 'invalid token' (koa-jwt default) then the client sends the refresh_token to the backed to require a new access_token (& optionally a new refresh_token). In this case I don't fully understand how the refresh_token is verified against the old access_token to provide a new token? Or why do we need to have a refresh_token?

Basically I just need generic advice on the upper topics (jwt updates and jwt expiration). Thanks

  • Woah, a lot of questions in 1! I may be able to answer some, I'll have a go, please don't downvote for not answering everything as that may take some time! – Julian Knight Oct 3 '16 at 9:34
  • OK, so not so many questions as first thought. I've updated the layout of the Q to make it a bit clearer. – Julian Knight Oct 3 '16 at 10:25
  • > If you are handling the MITM issue, you will have additional, server-side security in place to validate user tokens. In that case, you can afford to have longer lived tokens. I assume you mean something beyond standard token verification for each call? What type of security measures would those be? – Bambi May 12 '17 at 13:13
1
  1. "is it okay to create a new token when some of the credentials change"

    Absolutely. Tokens should generally be short-lived anyway so creating a new one isn't a problem.

  2. The answer here partly depends on how you are handling the man-in-the-middle replay attack problem with JWT. If you aren't doing anything, your tokens need to be very short-lived but you may not want your clients to have to constantly log back in. That's where the refresh mechanism comes in. It gives you an optional intermediate capability to refresh tokens without a full login.

    If you are handling the MITM issue, you will have additional, server-side security in place to validate user tokens. In that case, you can afford to have longer lived tokens.

    Either way, if the users change their security details in any way, it seems sensible to invalidate the token and require another login. But it is entirely up to you. You need to understand the value of the users and their sessions and the risks. When you understand that, you can sensibly decide how much risk you want to carry and how best to mitigate the risk you don't want to carry.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.