Hacker News new | ask | show | jobs
by s_y_n_t_a_x 2315 days ago
> to revoke a JWT you have to blacklist it in the database so it still requires a database call to check if it's valid.

The blacklist is smaller than storing every token and not needed if you use a short expiration and refresh often.

> JWT are to prevent database calls but a regular request will still hit the database anyway.

It's one less query per request plus not all requests need the database immediately.

> JWT are very large payloads passed around in every request taking up more bandwidth.

They are 100~ bytes instead of 10~, not "very large".

> If user is banned or becomes restricted then it still requires database calls to check the state of user.

This is the blacklist you mentioned as the first reason.

> JWT spends CPU cycles verifying signature on every request

Pretty sure this is neglible. Similar to SSL requests.

> JWTs just aren't good for authentication which is how a lot of web developers try to use them as. Use a session ID instead.

Opinion. I weighed the pros and cons and JWTs are still worth it for my authentication use cases.

1 comments

More power to you. I prefer to use the best tool for the job which in this case are session IDs since they are simpler, have been battle tested, and proven to work for over the last two decades.
I too love the best tool for the job, which is why blanket statements saying session IDs should always be used for authentication are very puzzling to me.

HTTPS, HMAC and asymmetric keys are battle tested and proven to work as well, that was one major point of the article.

I didn't say that they should "always" be used for authentication but that session IDs fulfills most web app user authentication needs. Most devs that implement JWT treat them as stateful which defeats the purpose of them. JWT has it's use cases when done correctly.
You said "JWTs just aren't good for authentication" which is pretty definitive.

I'm not sure you read the article because the points you are making were addressed.

Session mechanisms are all too often different across every web stack though, so if you have a variety of services and applications behind a single logon, you need to solve an O(n) problem that JWT makes O(1).