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

Stop using JWT for sessions (2016)

cryto.net

Post reply on HN
Print view View original

31–40 of 255 posts

Re: Stop using JWT for sessions (2016)

#31

Post by dperfect »

anonymousJim12 wrote: post #15
tehlike wrote: post #14

Earlier quoted context omitted.

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

How do you encode it in such a way that you can invalidate individual tokens? How do you distribute that information among your services?

In the past, I've compared the "iat" (issued at) value with a column in the users table called "invalidate_tokens_before". If I need to invalidate tokens for a user (for my use case, it would always be all tokens for a user at once), I just touch that timestamp column. True, it still required a db lookup (one that happens anyway), but I found that easier to manage than storing and managing session tokens.

Re: Stop using JWT for sessions (2016)

#32

Post by nbevans »

staticassertion wrote: post #22

Can someone explain the Cookie vs LocalStorage thing? You can access cookies from Javascript, so how is localstorage worse? Assuming an attacker can execute arbitrary js in the browser (the model provided by the article). edit: Thanks for the answers - httponly, makes sense.

You can't access a cookie from JavaScript if it is marked with the HttpOnly flag.

Re: Stop using JWT for sessions (2016)

#33

Post by miskin »

staticassertion wrote: post #22

Can someone explain the Cookie vs LocalStorage thing? You can access cookies from Javascript, so how is localstorage worse? Assuming an attacker can execute arbitrary js in the browser (the model provided by the article). edit: Thanks for the answers - httponly, makes sense.

If you set cookie httpOnly, Javascript cannot see it. So some malicious third party library or XSS attacker cannot steal session. It can still do requests and cookies would be included, so stealing is the main difference.

Re: Stop using JWT for sessions (2016)

#34

Post by ATsch »

staticassertion wrote: post #22

Can someone explain the Cookie vs LocalStorage thing? You can access cookies from Javascript, so how is localstorage worse? Assuming an attacker can execute arbitrary js in the browser (the model provided by the article). edit: Thanks for the answers - httponly, makes sense.

> You can access cookies from Javascript, so how is localstorage worse?

You can access it via JS only if you don't set the httpOnly flag on the cookie.

Re: Stop using JWT for sessions (2016)

#36

Post by nbevans »

JWT is an authentication token - it isn't session state. Session state changes during the lifetime of a session. Whereas the authentication token does not - other than for renewals. Overloading the authentication token to also store unrelated domain concepts such as shopping basket items is a gross abuse of its purpose. Given that generating a JWT token is computationally expensive I really doubt that many people are doing this like the premise of the article suggests.

Re: Stop using JWT for sessions (2016)

#37

Post by scient »

csours wrote: post #7

We have a requirement that users be logged out after 30 minutes of inactivity, so JWTs are perfect for our use case.

Except cookies are quite literally perfect for that - set the expiration to 30 minutes from issuance and it will automatically be expired with inactivity. Or bumped on activity.

Re: Stop using JWT for sessions (2016)

#38

Post by ivanhoe »

dperfect wrote: post #31
anonymousJim12 wrote: post #15

Earlier quoted context omitted.

How do you encode it in such a way that you can invalidate individual tokens? How do you distribute that information among your services?

In the past, I've compared the "iat" (issued at) value with a column in the users table called "invalidate_tokens_before". If I need to invalidate tokens for a user (for my use case, it would always be all tokens for a user at once), I just touch that timestamp column. True, it still required a db lookup (one that happens anyway), but I found that easier to manage than storing and managing session tokens.

And how is that better than using sessions in the first place? What is your gain?

Re: Stop using JWT for sessions (2016)

#40

Post by labourcurious »

staticassertion wrote: post #22

Can someone explain the Cookie vs LocalStorage thing? You can access cookies from Javascript, so how is localstorage worse? Assuming an attacker can execute arbitrary js in the browser (the model provided by the article). edit: Thanks for the answers - httponly, makes sense.

The author glosses over this but what they mean is that you can set the HttpOnly flag on cookies to prevent them from being accessed via JavaScript.
Post reply on HN