6

So this is kind of an odd scenario, but bare with me. My client has been issued a JWT token. After having received and stored it, I completely reset the database, and so also emptied the users table. Note that we're using MySQL with auto incrementing ID, whose counter has been reset. The user ID is stored in the JWT, so now the JWT isn't referencing an existing user anymore, so the client will get a 401. The problem arises when a new user registers and is inserted in the new database. That user will get ID 1, and so the old token for the other user will suddenly be valid for another user. I know it's an odd case, but is this a flaw in JWT? I guess an easy solution would be to use random ID's, but I'm still wondering.

Comments
  • 5
    You could use guids as IDs rather than numerical IDs to prevent that sort of issue.
  • 4
    Or change your JWT secret, so that the client's key just wouldn't work, regardless of the user ID inside it.
  • 1
    @BashouT Yeah, that'd be a solution, but I feel like there should be some other way.

    @xprnio Guess that would actually be the best thing to do. The one problem I can think of though is that it isn't automatic. But still a pretty good solution :)
  • 2
    @ScriptCoded Most places prefer guids to IDs normally to prevent sequence based attacks anyway, I'd say unless you have a good reason to use numerical IDs I would go with a guid
  • 1
    @BashouT Yeah and we will switch to it before launching (it's easier in development). Though I wanted to know anyways
  • 1
    Normally jwt token have an expire time and of course like @ScriptCoded said a build server that switches secrets on release is not a bad idea.
Add Comment