Is my JWT refresh plan secure?

1
votes

I plan on using JWT for my login system for mobile devices. There is no real standard workflow for refreshing JWT tokens I could find so I created this one below. The reason I want to use JWT is for performance reasons. Instead of checking if a user is valid with a database call for every single request I trust the JWT.

I have the proposed workflow which I want to implement into my app. Is this acceptablly secure? Efficient? Are there any obvious problems I am overseeing? What reasonable improvments can be made?

User logs in

  1. If no HMAC signed token exists inside of localstorage, the user gives a name to the device.
  2. DeviceName gets sent to the server where it is inserted into database.
  3. JWT token + HMAC signed token of the DeviceName are sent back to user. The HMAC signed token is put in place to make sure the jwt token (containing DeviceName) is sent from the same device that called it originally.
  4. JWT token is valid for X hours so a user can make any calls for X hours.
  5. After X hours, the JWT is expired. When a request is made the server can see the JWT is expired. Server will now attempt to refresh the JWT token. Server checks the database to see if the DeviceName specified in the HMAC signed token is the same as a valid device name in the database for that user.
  6. If so, create new JWT valid for another X hours, if no, send back message to require login.

If an account is compromised:

User can log into my password service. Once logged in, I would retrieve all the devices for that user, the user can then revoke their compromised device. Once this is done, a request to refresh the JWT will not work with the stolen token.

All of this of course happens over SSL.

My concerns which I have no solutions for:

  • If a JWT token is stolen the attacker has X hours to make calls based on the victim. I think this is the nature of tokens though and an accepted risk?

  • If the JWT is stolen, that means there is a good chance the HMAC token containing the device name is also hijacked so the user could refresh tokens until the victim realizes their account is compromised and revokes access. Is this accepted practice?

1
securityauthenticationoauthtokenjwt

1 Answers

0
votes

The first rule of crypto is “Don’t roll your own crypto” https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own

So have a look at the variety of libraries available on https://jwt.io

I’m not a crypto expert, so I’m not going to say you plan/workflow correct or there are no flaws. However some general comments: 1) What happens if I label two devices as ‘computer’? Have you considered what happens if everyone calls a device ‘phone’? Will everyone have the same HMAC device token?

5) After X hours the JWT token is expired, isn’t this too late for refreshing, define a clear refresh window. E.g. Token expires after X hours and then can not be refreshed, attempt to refresh it after X-1 hours.

Your first concern: Once a token is stolen, its too late. The aim is to secure the token so that doesn’t happen in the first place.

Your second concern: If I managed to get one of your token, assume I got both. If I have your token(s) I am you, and I can refresh the token. You could consider having a max expire or max number of refreshes to limit this.