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

51–60 of 255 posts

Re: Stop using JWT for sessions (2016)

#51

Post by drinchev »

tehlike wrote: post #14
drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

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

What's the point of having a token if you need to check it with a database on every request?

Instead of `SELECT isValid from tokens where token=""`, why not `SELECT user from sessions where session=""`?

Re: Stop using JWT for sessions (2016)

#52

Post by deathanatos »

scient wrote: post #37
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.

You shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.)

(Now, if you mean looking up a session token in a database and checking that for expiry, then yes, that works, but the only real difference between JWT and tokens then is the latter requiring a database query.)

Re: Stop using JWT for sessions (2016)

#53

Post by detaro »

jesseb wrote: post #23

From my time browsing HN, the consensus seems to be "don't use JWTs". What is the preferred method of client authentication for simple APIs these days?

Tokens checked against server-side sessions. OAuth 2 is common to obtain them. (The tokens can of course be JWTs if you want their content to be transparent, but the key is to not rely on the metadata in the token alone for verification)

Re: Stop using JWT for sessions (2016)

#54

Post by donatj »

franciscop wrote: post #46

If an attacker can read the user's localStorage you have much bigger issues to worry about: XSS, physical access, no TLS, etc. With any of those, the token is the least of your concerns; an attacker can make API calls, read the data, etc anyway, no matter if its JWT or sessions. So, IF (which is a big if) you implement everything correctly then you have to do two "extra" steps with each tech: - Blacklists (or Whiteli…

"If an attacker can read the user's localStorage"

9/10 the attacker is the user.

Re: Stop using JWT for sessions (2016)

#55

Post by nbevans »

drinchev wrote: post #9
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.

What about a stolen user password and an actor, who already uses your token? Can the targeted user kick him out by resetting his / her password?

Sure why not? Each user account has a counter or timestamp on it in the user registry. If the JWT token in the request passes crypto validation but it has an older counter/timestamp than held in the user registry then it is deemed invalid and the user must re-authenticate. This is still a horizontally scalable design.

Re: Stop using JWT for sessions (2016)

#56

Post by the_af »

ivanb wrote: post #45

Many in the comments are curious about blacklisting JWTs. No, you don't need to put the whole token on a blacklist. Give your tokens reasonably unique JTI claim[1] and put the affected JTIs on the blacklist. The benefit of JWTs is that token blacklists are usually much shorter than hypothetical token whitelists. [1] https://tools.ietf.org/html/rfc7519#section-4.1.7

What if the blacklist becomes unavailable? The author addresses this in part 2.

Re: Stop using JWT for sessions (2016)

#58

Post by nbevans »

scient wrote: post #37
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.

Cookies are implementation dependent. It's quite possible that a user agent doesn't honour what you instructed it to do regarding the expiration of a cookie.

JWT however... your server side can validate its own token in whatever ways it wants (including expiration). You can't get more secure than that.

Re: Stop using JWT for sessions (2016)

#59

Post by [deleted] »

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.

[deleted]
Post reply on HN