Comment by slau | Hacker News Reader

Comment by slau | Hacker News Reader

While it’s a nice write-up, I’m not sure I’m following some of the sweeping conclusions the author makes regarding security and purpose.

> JWT Tokens

> Cons: Susceptible to token theft (e.g., XSS attacks) if not handled carefully. Must be short-lived or use refresh tokens.

>

> Session Tokens

> Pros: Generally more secure as they rely on server-side storage, mitigating issues like token theft.

>

> Cons: Vulnerable to CSRF attacks if not handled properly.

Isn’t session token theft as much of an issue as JWT token theft? Why is there a difference in security just because in one case it’s a JSON blob that says user_id:4,is_admin:false and in the other it’s an opaque string? Surely session tokens are equally vulnerable to XSS as JWT tokens?

The author then claims that JWT are “potentially faster since no server-side lookup is required. However, JWTs can be large in size”. How large? How does it affect things? Does it affect request latency, or server time decoding the JSON? The comparison with session tokens is then made: “server-side lookup, which can introduce latency, especially with a high number of active sessions”. Where is the latency introduced? Because an RDBMS is slower when there’s many rows in the session table? Because Redis can’t do an efficient GET?

This article is a whole bunch of vague trueisms. The author clearly knows some stuff about it, but isn’t able to articulate it well enough to help the reader make a good decision or walk away better informed than having not read it.

It almost feels cargo culty.

Edit: could we finally get proper quoting support?

> Isn’t session token theft as much of an issue as JWT token theft? Why is there a difference in security just because in one case it’s a JSON blob that says user_id:4,is_admin:false and in the other it’s an opaque string? Surely session tokens are equally vulnerable to XSS as JWT tokens?

The difference is that if your session cookie uses HttpOnly (which should _always_ be the case) then it can’t be read by JS, which makes it less vulnerable to XSS than a JWT (or worse, a refresh token) stored in a cookie by the client or localstorage and therefore accessible to JS. Basically, you have to be more careful with how you handle JWTs, which makes it more likely for an inexperienced or careless dev to do something insecure like store a JWT in localstorage.

> How does it affect things? Does it affect request latency, or server time decoding the JSON?… Where is the latency introduced?

I think their point is that it’s faster not to hit the DB, assuming you aren’t hitting the DB for any other reason. Any performance optimisation should be justified and profiled. There aren’t many applications operating at a scale where the difference in performance between JWTs and session tokens is going to make a significant difference, and even fewer who can genuinely use JWTs without hitting the DB (eg, to ensure the JWT hasn’t been revoked)

> Isn’t session token theft as much of an issue as JWT token theft?

Session tokens can be revoked much more easily, say when a user logs out. A JWT token needs a revokation service to revoke early, and that adds a fair bit of additional complexity.

Also, assuming your client is a web browser (as is often the case) and you're sending the Authorization header, you have to store that JWT somewhere in the browser where it's not isolated from the rest of the scripts on your page (whereas session tokens are typically stored in opaque cookies with a lower chance of leaking to a malicious script).

Though I imagine you can also store JWTs as cookies, which wold mitigate that issue.

I thought the latest recommendation was to use JWTs with a 15 minute expiration. You could also put a JWT in a cookie. Also some implementations of a Session don't use a database lookup and need extra work to invalidate a session. Same lookup can be used on a JWT.

Yeah but then you give them a refresh token which you still have the same problem with.

> You could also put a JWT in a cookie.

Yep, I mentioned that also

> Isn’t session token theft as much of an issue as JWT token theft?

I think the author focused too hard on the association between JWT and how they are sent through the Authorization header, and session tokens and how they are stored as cookies.

My guess is that the author confuses session tokens with a very specific frontend implementation of session tokens, and proceeds to base his comparison on those contrasts.

I did notice, when looking up resources online about JWTs, that a lot of folks out there are under the mistaken understanding that JWTs and "bearer tokens" mean the same thing.

Reply on news.ycombinator.com