Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
TobiSGD2815yI would say: it depends on the lifetime of your tokens. If you have very short lifetimes then an attack stealing a token is almost useless. If you have long-lived tokens, then yes, it is usefull, it let's you store a token in a blacklist, so that it can't be used anymore.
-
Mb3leb21985y@TobiSGD my colleague said that it's only a client side issue you just remove his token and he will be out
-
LMagnus20635yYou should always give the client the option to logout regardless of the technology for security reasons.
-
olback109955yThe only thing the logout button would do is delete the token locally and redirect to the home/login page. That's how I have it setup at least.
-
Mb3leb21985y@LMagnus but the question should it be handled from the server side from the rest API or you think it's a client side
-
olback109955y@Mba3gar Unnecessary unless someone stole the token. This can be handed other ways though.
-
olback109955y@Mba3gar in the payload, include a bust (random value). When a user registers, generate a random string and store that in a database together with the password hash and username or whatever. Whenever you want to deauthenticate the user, change the bust. Whenever the user makes a request, the bust has be checked against the DB of course.
-
LMagnus20635y@Mba3gar should be the backend API. Anything client side can be manipulated so for security the backend must manage the authentication state. Front end can of course assist with this for a better user experience.
-
Konsole31245yLike @TobiSGD said. If tokens are of long duration, you must provide mechanism to blacklist them.
-
Konsole31245y@olback Doesn't that defeat the primary purpose though? You are making a db hit for every request
-
Konsole31245y@olback I usually prefer 2 token system. Access token and refresh token. RT can be blacklisted. This provides blacklist mechanism and reduces load on db.
-
Mb3leb21985y@olback then do you have any documentation about this ? It seems interesting taking into consideration that doesn't make the process any slower ?
-
Konsole31245y@olback I think applying your method on RTs makes more sense. Checking for blacklisted tokens seems to be computationally more intensive.
-
Konsole31245y@Mba3gar Ok. Googled it. I mainly work in Python(Django) so don't require passport.js.
I have worked little with node but don't remember using passport. I remember some other library. -
Mb3leb21985y@Konsole ah okay got your point. Am planning to create a very secure API endpoint and am a little bit worried about few security measures specially from the backend and how to handle the token on login, middlewares and on logout as well as it's lifetime
-
Kage9255yisn't the whole point of JWT tokens that it doesn't require any database queries or whatever to authenticate?
making a blacklist of these tokens would remove that, since you'd have to compare the token.
I think removing it client sided when logging out is sufficient. The client is logged out and no-one else on the device can just log in because the token isn't stored anymore locally -
hjk10157495yThere should be no need of a blacklist. The valid tokens hit storage. As soon as a token needs to be invalidated it is removed from the "whitelist". No extra blacklist queries, same effect.
If the token needs to be blacklisted because of reuse or guesswork than you have an security issue anyway. Just use standards and libraries that exist for this purpose already.
If one token/user lookup is an performance issue you should go with a refresh token design. Short lived (access) token can be cashed in memory. When this token also needs to be prematurely removed server side you need an invalidation subscriber so the token invalidation can be pushed to all caching instances. -
jimshorts145yAnd this is why I'm always in meetings with 18 people because it takes that many people to finally be correct
-
Konsole31245y@Kage you can do that only if your tokens are very short lived. Otherwise if anyone gets the token, you are doomed.
But keeping tokens short is bad ux as it will force the user to login every few minutes.
Thus I usually put 2 token system.
Access tokens and Refresh Tokens
Access tokens don't require db hit and are very short lived.
Refresh tokens can be used to get new access tokens and can also be blacklisted.
Btw, coming to the part of db access. There is still a lot of debate. Because in many cases , you actually end up doing a db access anyway in order to obtain user's info. -
Konsole31245y@Kage Say I somehow get your token and you know it. There is basically no way for you to stop me from accessing your account and perform malicious tasks.
If token is short lived, at least there is only a short time in which I can perform malicious activities
Related Rants
Is logout useless on a Rest API that uses JWT token?
Discuss
rant
rest api
api
discussion
jwt
backend
token