7 ms·
Reasons why JWTs are not awesome: - 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. - JW
by miguelmota 7y ago
Reasons why JWTs are not awesome:
- 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.
- JWT are to prevent database calls but a regular request will still hit the database anyway.
- JWT are very large payloads passed around in every request taking up more bandwidth.
- If user is banned or becomes restricted then it still requires database calls to check the state of user.
- JWT spends CPU cycles verifying signature on every request.
- JWTs just aren't good as session tokens which is how a lot of web developers try to use them as. Use a session ID instead.
Where JWT works best:
- when a client can interact with multiple services and each service doesn't need to do a network request to verify (ie federated protocols like OpenID). The client verifies the user's identity via the 3rd party.
- as a 1 time use token that's short lived, such as for downloading files where user gets a token requested from auth server and then sends it to the download server.
- s_y_n_t_a_x 7y 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.
- miguelmota 7y agoMore 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.
- s_y_n_t_a_x 7y agoI 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.
- miguelmota 7y agoI 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.
- s_y_n_t_a_x 7y agoYou 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.
- barrkel 7y agoSession 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).
- jayd16 7y agoI think they're quite good at authentication. They're less good at authorization when you want to update that faster than expiry times. Once you go down the path of checking a DB along side the JWT your design has gone off the rails. Either the expiry works for you or it doesn't. Don't try to "fix" it.
- tracker1 7y agoDon't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.
- drinchev 7y agoSo where do you store the ones that should not allow to be refreshed? How short lived they should be in case of "Reset Password" scenario, when you need to kick out malicious user?
- kissgyorgy 7y agothat's the whole point. That's the trade off you make, you DON'T implement those features. When you need that, it doesn't make sense to use JWT. Right tools for the right job...
- labawi 7y agoGP was talking about every request hitting the DB. A once in 10 min refresh should not be an issue.
- tracker1 7y agoYou can still do a redis or memcached, or even an rdbms table for that matter on revoked tokens... and do a lookup for critical systems... You don't need to do that on EVERY request though. It's really not less difficult than a session server/service/database, and more likely to scale better.
- jteppinette 7y agoStakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our system more simple and decreases database calls, increase performance, ...” Stakeholder: “nope”
- tracker1 7y agoUsually in one of those scenarios, you will try to hold, say a fired employee for that long in order to deactivate all their accounts and access anyway... in reality it's not much of an increased risk... You still could blacklist, but realistically most areas don't need a dedicated revocation check. Some critical areas might, depending on the space.
- holtalanm 7y agoif you have gotten to the point where you need to hit the database to verify the JWT, something is wrong. Either need to turn down your JWT expiry time, or refresh your JWT more often, or both.
- cameronfraser 7y agoNot everyone needs to blacklist JWT's. If you use short sessions this will almost never be a problem.
- sumnulu 7y agoThere will be very few black listed tokens, and they are ephemeral. You can use memory replicated datasets, such as CRDTS or just broadcast the whole BL token list to all nodes. For the size argument, you can use cbor instead of json. (CBOR Web Token) CWT https://tools.ietf.org/html/rfc8392 https://tools.ietf.org/html/rfc8392