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

201–210 of 255 posts

Re: Stop using JWT for sessions (2016)

#201

Post by luhn »

anon1252 wrote: post #197
redbeard0x0a wrote: post #130

Earlier quoted context omitted.

Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs)

> Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs) I don't see why one can't use redis to persist sessions at first place and why your list of revoked token would be limited to 100.

It's not explicitly limited to 100, but only a small portion of tokens will be revoked, so your revocation list will be small.

Re: Stop using JWT for sessions (2016)

#202

Post by AndrewSChapman »

enraged_camel wrote: post #177
AndrewSChapman wrote: post #133

I'm not 100% sold. I think JWT's are fine in some situations as long as you know the limitations. Regarding session invalidation, I would handle this in two ways. 1. Support a "Log everyone out" function by storing a simple version number in the JWT. If the version constant in your app is different to the number in the JWT, it is invalid. 2. Support a "I need to logout user X function" by storing a blacklist of token…

>>2. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS. Again though, the whole point of JWT is to completely avoid server-side state management. The moment you store state somewhere (whether a list of valid tokens or a shorter list of invalid tokens) you have re-invented the concept of sessions, so why not use that instead?

How about instead of "the whole point of JWT is to completely avoid server-side state management" we think of it as "the whole point of JWT is to reduce the overheads of server-side state management".

In my answer above, I was pretty clear about how the load on the database can be significantly reduced with a blacklist and optionally Redis out front, thus allowing JWT to significantly reduce the burden on the database.

Re: Stop using JWT for sessions (2016)

#203

Post by arithma »

Are there any engineering books that have a collection of best practices for internet engineering problems similar to this one? I find that most of this information is learned colloquially, or through what other frameworks do.

Re: Stop using JWT for sessions (2016)

#204

Post by Spivak »

jrochkind1 wrote: post #64
tehlike wrote: post #24

Earlier quoted context omitted.

Yes, of course, jwt can facilitate that. Using it as a replacement is not good, i agree.

But what value is it adding over ordinary 'bearer token' sessions in that case?

When you aren't invalidating tokens your app server can serve all static but restricted content without checking with the DB.

Re: Stop using JWT for sessions (2016)

#205

Post by dperfect »

the_af wrote: post #138
dperfect wrote: post #106

Earlier quoted context omitted.

Again, I’m not arguing that traditional sessions are bad and JWT is categorically good. Of course, if everything is already implemented for you[1], then ease-of-use is less of an issue, but there are valid use cases where JWT makes sense (it isn’t categorically “bad” as the author tries to show). For some of my particular use cases[2], I happen to prefer the JWT approach (despite all the points given in the article,…

> there are valid uses cases where JWT makes sense (it isn’t categorically “bad” as the author tries to show). The author does sound negative, but doesn't claim JWTs are categorically bad; he actually mentions cases where JWTs are useful: when they are used as single-use tokens. The author claims JWTs as sessions are too problematic to be useful. > I’ve seen some pretty terrible security issues in both JWT and framew…

The "battle-tested" argument is becoming less and less obvious. As for being error-prone, I've seen a lot of people set up their session cookies incorrectly/insecurely when using traditional session tokens (and framework-provided authentication libraries), so I'd guess the two approaches are about on equal ground in the "error-prone" department.

Re: Stop using JWT for sessions (2016)

#206

Post by jjeaff »

detaro wrote: post #181
cryptica wrote: post #171

Earlier quoted context omitted.

This article is propaganda. This is not the first article of its kind; they just keep popping up over and over on HN with the same poor arguments. I usually take the time to write long explanations as to why these points are invalid but I'm tired of arguing with these people. The real reason for these articles I think is that some developers had a very traumatic experience with a poorly implemented JWT authentication…

Could you explain why they're important for WebSockets? Hadn't heard about them in that context before.

Probably just because web sockets tend to be used for frequent updates and jwt allows you to authenticate a user without necessarily pinging your sessions table on every single call.

Re: Stop using JWT for sessions (2016)

#207

Post by unclebucknasty »

kbenson wrote: post #190
unclebucknasty wrote: post #183

Earlier quoted context omitted.

> It's a trade off But, what are you getting for this added complexity--above and beyond what "traditional" user session management provides?

You can serve pages that don't require DB access without ever hitting the DB. Static content that is restricted to authed accounts is able to be served immediately and directly. Requests that access resources other then ones shared with the auth system do not need to first access the auth system to verify the account. Even if the auth system is on the same DB as the rest of the content, it's no longer a sequential bo…

Yeah, I can see scenarios where these features would be useful, but wonder how many architectures truly benefit from it? I'd guess that a good many people implement JWT b/c it's the accepted approach or in premature anticipation of a future scaled-out architecture that would land it more in one of the beneficial scenarios.

Of course, if the DB concern is one of performance, then there's also a performance trade-off with JWT since the (sometimes large) token is constantly transferred over the wire and compute is used to decrypt it. That may be faster than a DB-round trip, but it's not free. Of course, "old-school" session-management keeps the auth state in memory server-side, which can be the fastest--though comes with a memory hit. But, constantly processing the token in-memory also assigns a memory penalty (even if slightly more transient).

In any case, I think it's like a lot of popular tech that evokes strong reactions on both sides: The success of the tech causes it to be overused, invariably in use-cases for which it isn't as well-suited or was not originally designed.

In this case, the important need for session expiration alone makes me question hard whether JWT is a good fit for session management in a lot of user-facing apps. In some cases it will be, but in others, there are probably better solutions.

Re: Stop using JWT for sessions (2016)

#208

Post by Spivak »

the_af wrote: post #134
xyzzy123 wrote: post #108

Earlier quoted context omitted.

Then your application is unavailable, just like it would be if your session table went away? I don’t get this complaint. The advantage is that you can use a loosely consistent datastore with expiring entries and few records at any given time. There’s lots to love about the approach.

> Then your application is unavailable, just like it would be if your session table went away? The author replies: "congratulations, you've just reinvented sessions, with all their problems (like centralized state) and gained nothing in the process", and also with an implementation that is "less battle-tested". My own opinion: loose consistency can work in some circumstances, but seems a security risk in others.

But we've drastically reduced the amount of central state, the complexity of managing it, the time it takes to access it, the danger of losing it, the performance impact of updates to it, while making the happy path to your site faster.

Revolutionary, maybe not, a solid improvement on the traditional design of sessions, I think so.

Re: Stop using JWT for sessions (2016)

#209

Post by Alex3917 »

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…

> This means that you cannot, for example, invalidate the session of an attacker after detecting a compromise. You also cannot invalidate old sessions when a user changes their password.

Sure you can. Just have a 'date_password_last_changed' field on your user model, and compare that with the issued_at date on the jwt. Since your user model presumably gets retrieved for each authenticated request anyway, there are zero extra database lookups. Similarly, if there is a global compromise then just rotate the secret key use used to signed the JWT.

Re: Stop using JWT for sessions (2016)

#210

Post by Alex3917 »

enraged_camel wrote: post #70
drinchev wrote: post #51

Earlier quoted context omitted.

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=" "`?

Exactly, the moment you add statefulness you've basically reinvented session authentication.

There are a lot of problems with storing cookies when the front end and back end are hosted on different domains though. That is the main reason why people use JWTs with SPA apps, because otherwise it wouldn't really be possible to serve the front end from a CDN. Most people using JWTs aren't using them because they're stateless, but rather because it's the only way to solve the problem.
Post reply on HN