JWT Tokens vs. Session Tokens | Hacker News Reader

JWT Tokens vs. Session Tokens

oguzkurukaya.medium.com

21 pointsthunderbong10 comments

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?

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.

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

You can store the JWT in a central database and use it in the same way as a session token. And you can put a revocation URL into the claims. But JWT has still the null cipher problem.

If you store a JWT in a secure https only cookie, you get most of the security pros of the session token, but not the downsides. You are still stateless. Yes, do not store JWTs in localStorage or such, this is not good practice. If a session tokens gets stolen, you eventually are able to revoke it, but in real life you won't, because you won't recognize the theft in most of the cases. On the other hand, with JWTs you are still able to block database access for the specific user, when it comes to a case of identity theft. This mitigates also. The article is optioniated and vague, which is absolutely fine. :-)

you can put a session token in a JWT token with a short life to prevent your database from being pestered, only bothering it when the JWT expires and reassign a new one (JWT). The downside is if you revoke the session token you have to wait for the JWT to expire before the login is over.

Reply on news.ycombinator.com