Live data from Hacker News

JWT is Awesome

thehftguy.com

121–130 of 170 posts

Re: JWT is Awesome

#121
post #85
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.

An organization I was at in the past attempted to use them as a replacement for sessions, which turned out to be a terrible idea as I suspected it would. I've found that arbitrarily re-inventing the wheel because a new thing becomes popular should be done deliberately and with great caution. More generally - I think it's important to look for solutions to fit a specific problem, not problems to fit a specific solutio…

Author. I wouldn't recommend to do less than 2-5 minutes. Some OpenID Connect providers actually ignore token expiry time silently when it's below a couple minutes.

Consider that host clocks are not always in sync (even NTP could leave 10 seconds of difference) and the many authentication redirections can take quite a bit of time for slow clients. Limiting tokens to 30 or even 60 seconds is asking for troubles.

But then again, I have to work with thousands of hosts, applications and datacenters, so I feel every edge cases. A single application on a single host would not.

Re: JWT is Awesome

#123

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…

Not everyone needs to blacklist JWT's. If you use short sessions this will almost never be a problem.

Re: JWT is Awesome

#124

JWTs have made client side auth integrations look better. But the problem is that common security considerations and implementation details are generally overlooked. 1. Tokens are typically stored in localStorage. (app becomes vulnerable to CSRF & XSS attacks). 2. Tokens can be stolen. Now this is generally controlled by having a very short expiration time. 3. Short expiration times mean persisting refresh tokens to…

I think you're mistaken on point one, sites that use localStorage to store tokens are not in general susceptible to CSRF attacks [1]. The reason being that seperate domains can't access eachothers sessionStorage or localStorage in the browser. In fact that's one of the advantages of using the DOM storage APIs over sessions/cookies [2].

1. https://stackoverflow.com/a/35347022

2. https://youtu.be/WlmKwIe9z1Q?t=3658

Re: JWT is Awesome

#125

Earlier quoted context omitted.

Popularity definitely is value when designing APIs for public consumption. JWT has a concrete edge here. This is why I asked HN about their opinions on Paseto, if there's a chance it'll overtake JWT/JWE in popularity, then that makes it more suitable for APIs. In the context of security, popularity has the added benefit that there's enough eyeballs, so all bugs are shallow.

Author here. As a matter of fact, the world has already settled on JWT. Paseto is dead in the water and will never gain any traction. Every single company has no choice but to support JWT in some capacity. Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SA…

> Paseto is dead in the water and will never gain any traction.

We'll see about that. :)

> Every single company has no choice but to support JWT in some capacity.

This will change soon.

> Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).

The plan for PASETO has always been to make it a JWT alternative for OIDC.

First comes the XChaCha RFC.

Second comes the PASETO RFC.

Finally, the OIDC-PASETO RFC.

1. https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03

2. https://github.com/paragonie/paseto/blob/master/docs/RFC/pas...

3. https://github.com/paragonie/paseto/issues/5

Re: JWT is Awesome

#126
post #77

Earlier quoted context omitted.

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

You can use symmetric, sha256

Symmetric signatures completely kill ability to verify token without secret.

For python I had to glue and stick python_jwt with cryptography primitives to do ed25519.

And the most funny thing: very few clients will understand these "standard" JWT tokens.

Re: JWT is Awesome

#127
post #17

would you secure api via JWT? Session token are not an option, basic auth can be an alternative.

JWT works well. Securing API is one of its main use cases.

That being said. Please do NOT use basic auth for anything in 2020. This is the worst anti-pattern one could do for authentication.

Basic auth simply transmits the username and passwords in clear text with every request. No application should be receiving username and password in clear text besides a single auth service. The passwords will get leaked all over the place between developers debugging, verbose logs, exceptions, etc... And unlike tokens that are meaningless and expire, textual passwords last forever and are extensively re-used by user across websites.

Re: JWT is Awesome

#128

Earlier quoted context omitted.

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.

Re: JWT is Awesome

#129
post #40

Earlier quoted context omitted.

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…

Off topic: it gives me undue vexation that there are two dessert items with names so similar to each other that everyone keeps confusing them. Can we just all agree to come up with a new name for one of them?

To be fair, there is a similar situation with "cookie", which means any kind of small, flat, compact, unleavened flour-based sweet baked item in the USA, but more specifically a particular soft kind in the UK.

And conversely, "biscuit", which has the former meaning in the UK and means some sort of weird scone in the USA.

Re: JWT is Awesome

#130

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

So 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?
Post reply on HN