Is logout useless on a Rest API that uses JWT token?

Discuss

I 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.

@TobiSGD my colleague said that it's only a client side issue you just remove his token and he will be out

@irene tokens are never the same

@irene so?

You should always give the client the option to logout regardless of the technology for security reasons.

The 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.

@LMagnus but the question should it be handled from the server side from the rest API or you think it's a client side

@olback someone said here it should blacklist a token once logout what do you think

@Mba3gar Unnecessary unless someone stole the token. This can be handed other ways though.

@olback then what's the security measures you can take ?

@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.

@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.

Like @TobiSGD said. If tokens are of long duration, you must provide mechanism to blacklist them.

@olback Doesn't that defeat the primary purpose though? You are making a db hit for every request

@Konsole wouldn't you do that if you had a blacklist as well?

@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.

@olback then do you have any documentation about this ? It seems interesting taking into consideration that doesn't make the process any slower ?

@olback I think applying your method on RTs makes more sense. Checking for blacklisted tokens seems to be computationally more intensive.

@Konsole do you use passport jwt token by any mistake ?

@Mba3gar What is passport jwt?

@Konsole how do you generate token? Isn't by jwt or passport ?

@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.

@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

isn'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

There 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.

And this is why I'm always in meetings with 18 people because it takes that many people to finally be correct

@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.

@Konsole why would it not work with tokens which expire after 2 weeks or so, a normal time for an user to be logged out for inactivity.
You can refresh the token if they are active.

@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