0

So a user logs in successfully, and they get a valid JWT that we store as an encrypted cookie in their browser.

Later down the road, we want to revoke this user's access, and we flip a boolean on the user model in the database - hasAccess: false - but the problem is that their cookie is still good.

To do a significant optimization, our server just looks at the token/cookie, and if it's valid, forgoes a trip to the database to look for the user model.

The only way I can think to solve this, is to store a hash of "blacklisted" usernames in memory on the server.

Does anyone know of a good way to solve this? Seen a similar problem?

  • 1
    have you tried: `JWTAuth::invalidate($token);` ? – Andy Nov 14 '17 at 19:20
  • I am using `require('jwt-simple')`...but the original problem is that I don't know when to invalidate the token. The database right now is the only thing that can tell me to invalidate the token, but I am try to save a trip to the database. –  Nov 14 '17 at 21:03
  • The only way I can think to solve it is to update the server when there is a change to the database to tell the server that user access has changed. The server will have to cache a list of invalid users, and then invalidate the token upon the next request with that token. –  Nov 14 '17 at 21:11
  • This solution is not scalable. If the number of invalid users is very high, then you will have to have a huge memory dedicated to storing the invalid user list at all times. It's better to make a trip to the database and invalidate the user. – mrtyormaa Nov 14 '17 at 21:14
  • You can keep a short expiration time. If your logic is to invalidate the user anyways why not expire it and give fresh tokens upon return. – mrtyormaa Nov 14 '17 at 21:20
  • @mrtyormaa I agree - in this case, we only have a few hundred users, so it will be ok, but I agree that in general my solution will not scale (using server memory to store invalidated users) –  Nov 14 '17 at 21:24

0 Answers0