Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JWT is Awesome

thehftguy.com

Post reply on HN
Print view View original

131–140 of 170 posts

Re: JWT is Awesome

#131

Post by s_y_n_t_a_x »

miguelmota wrote: post #128
s_y_n_t_a_x wrote: post #96

Earlier quoted context omitted.

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.

Re: JWT is Awesome

#132

Post by kissgyorgy »

drinchev wrote: post #130
tracker1 wrote: post #97

Earlier quoted context omitted.

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?

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

Re: JWT is Awesome

#134

Post by CiPHPerCoder »

Supermancho wrote: post #111
enumjorge wrote: post #71

Earlier quoted context omitted.

Can you elaborate why session IDs inside cookies is dangerous?

I can manipulate my cookies. I can forge my servserside session id for session hijacking. This is what I understood.

> I can forge my servserside session id for session hijacking. This is what I understood.

Forge this. For each session:

    session_id = bin2hex(random_bytes(32))
Yes, you can change what you send to the server. But you can't hijack another user's session in this probability space (2^-256) by blind guessing. Instead, you need another way to leak their credentials to hijack the session.

Re: JWT is Awesome

#135

Post by barrkel »

miguelmota wrote: post #95
s_y_n_t_a_x wrote: post #92

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.

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

Re: JWT is Awesome

#136

Post by sumnulu »

miguelmota wrote: post #86

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…

There 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

Re: JWT is Awesome

#137

Post by jteppinette »

tracker1 wrote: post #97
miguelmota wrote: post #86

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

Stakeholder: “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”

Re: JWT is Awesome

#138

Post by bearjaws »

jteppinette wrote: post #137
tracker1 wrote: post #97

Earlier quoted context omitted.

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

Stakeholder: “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”

Meanwhile on sales call with Microsoft:

"Authentication takes a few minutes to replicate throughout our systems so a SLO request should be resolved within a few minutes". Stakeholder: Ok sounds good

Re: JWT is Awesome

#139

Post by spookthesunset »

jteppinette wrote: post #137
tracker1 wrote: post #97

Earlier quoted context omitted.

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

Stakeholder: “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”

For parts of the site where you need to boot somebody instantly... just hit up the authentication server on every request to validate the session. For parts of the site where it doesn’t matter so much, wait for the token to expire....

It isn’t all or nothing.

Re: JWT is Awesome

#140

Post by labawi »

drinchev wrote: post #130
tracker1 wrote: post #97

Earlier quoted context omitted.

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?

GP was talking about every request hitting the DB. A once in 10 min refresh should not be an issue.
Post reply on HN