Live data from Hacker News

JWT is Awesome

thehftguy.com

91–100 of 170 posts

Re: JWT is Awesome

#91
post #64

Earlier quoted context omitted.

That's precisely the use case for JWT I recently had to work with, where cookies are irrelevant. The web server gets a token from the API server, then prepares a few JSON messages that the web client will send asynchronously with JS. Since each message content is signed, the web client can't tamper with what is sent to the API. JWT was perfect for this 3-tiers messaging.

I mean is all this complexity really worth "I can send data to an untrusted client so that it can later send it back to me?" compared to just storing that data somewhere like Redis?

Then you have to provide a consistent view of the database across all server nodes, and the database updates need to propagate to all of your servers more quickly than the clients can issue requests. How complex is JWT compared to that?

Re: JWT is Awesome

#92

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 ch…

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

Re: JWT is Awesome

#93

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 ch…

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

Re: JWT is Awesome

#94
post #77

Earlier quoted context omitted.

If your complaint is that RSA is outdated and ECDSA is backdoored by the NSA, use Ed25519, which JWS/JWT supports[1]. [1]: https://tools.ietf.org/html/rfc8037#section-3.1

> JWS/JWT supports Support for ed25519 signature in current implementations is pretty poor.

You can use symmetric, sha256

Re: JWT is Awesome

#95

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 ch…

> 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 a…

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.

Re: JWT is Awesome

#96

Earlier quoted context omitted.

> 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 a…

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.

Re: JWT is Awesome

#97

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 ch…

Don'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,.

Re: JWT is Awesome

#98
post #81

JWT is not awesome. I spent yesterday implementing it. The smallest usable JWT I could create was 137 bytes, not including the Authorization header. This is absurd -- the total amount of data I needed to store in the JWT was about 10 bytes. This inefficiency bloats requests. At a time when we're migrating to http/2, which which deliberately reduces headers to speed things up, JWT is going in the other direction.

You may only need 10 bytes of info, but that JWT is a lot more than just a data blob. It's a signed set of user info. If you don't need that extra layer, sure, then drop to an opaque token. Complaining that a signed header is large, however, seems a little silly. It's also worth mentioning that HTTP/2 also does header compression which helps with this.

Re: JWT is Awesome

#99
JWT - because you were told sessions and cookies aren't cool anymore.

Then you come to realize that JWT is basically pointless except for doing MFA (which you could probably have done with a random token).

Re: JWT is Awesome

#100
post #40
post #32

https://news.ycombinator.com/item?id=21785888 tptacek Credential attenuation in Macaroons is cryptographic; it's in how the tokens are constructed. I don't see the opportunity for a DoS (that didn't exist without attenuation already). Macaroons are a really lovely, tight, purpose-built design that happens to capture a lot of things you want out of an API token, including some things that JWTs don't express naturally…

I'd never heard of macaroons. Here is a website: http://macaroons.io/ I note that the logo depicts macarons [1], rather than macaroons [2]. A parent comment also mentions PASETO: https://paseto.io/ Sadly, a paseto does not appear to be any kind of biscuit. The PASETO site links to this searing indictment of JWTs and related things: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... I am far from qualifie…

> I note that the logo depicts macarons [1], rather than macaroons [2].

Partly (largely?) my fault. When we wrote the Macaroons paper, I was simply not aware that Americans use the French word when referring to the French variety of macaroons.

I think pedantry in auth should be celebrated.

Post reply on HN