well to be honest i'v never used blacklist tables ,i usually use refresh tokens.
check out this link below you may find a good strategy to deal with JWT on logout, there is a lot of infomations that could be very useful
(stackoverflow.com/questions/219786...)
Personally, I'm storing a unique hash in my database associated with the JSON web token's unique ID (you could also just store this in memory but as my application is still in the development stage it gets restarted often).
That way, when the user logs out, I can just remove their hash from the database and thus invalidate their session.
It's cleaner because then I don't have to worry about wiping old keys from blacklist tables - and I don't have to deal with refreshing the tokens.
Great tutorial :)
I guess it's also interesting how you invalidate JWT on logouts. Do you prefer any method? For example refresh tokens or blacklist tables?
well to be honest i'v never used blacklist tables ,i usually use refresh tokens.
check out this link below you may find a good strategy to deal with JWT on logout, there is a lot of infomations that could be very useful
(stackoverflow.com/questions/219786...)
Personally, I'm storing a unique hash in my database associated with the JSON web token's unique ID (you could also just store this in memory but as my application is still in the development stage it gets restarted often).
That way, when the user logs out, I can just remove their hash from the database and thus invalidate their session.
It's cleaner because then I don't have to worry about wiping old keys from blacklist tables - and I don't have to deal with refreshing the tokens.
Isn't the point of using web tokens that you don't need database access to users for every request?
I was going to say that the article could benefit from more exploration of why this is a good approach.
Good point, although this does minimize the amount of requests that you need to make to the database.