[johnduhart]

> I won’t get sucked into the session ID vs. JWT argument, but honestly, using JWTs in cookies is a win because you don’t have to fuss with storing session data on the server.

Okay, but then you implement storage of the refresh token and build this bespoke JWT re-issuance logic. So where's the win here? Just use sessions.

[maz1b]

What's wrong with storing JWTs in httponly cookies? Having a way to validate and track JWTs is a valid use case.

[unscaled]

1. Cookies remain valid on logout (unless you implement a session revocation mechanism). This can be mitigated by making the JWT live a very short time (e.g. 5 minutes), but you still don't get immediate expiry. This may not be acceptable if you need to comply with certain standards such as PCI/DSS, SOX or HIPAA.

2. Cookie size could grow much larger. It's generally not a huge concern if you don't stuff too much data into your JWT claims, but if you want to optimize traffic for slow networks, JWT is not a great choice.

3. Since 50% of the JWT standard (and 90% of the JWE standard) is made of broken and semi-broken algorithms, you need to be careful on what keys and libraries you use. Unfortunately, we cannot see the implementation for this article, so we cannot judge how safe it is, but JWT just requires extra care compared to Session IDs.

4. If you're using refresh tokens because your JWT is short lived, you're not really saving yourself any work, because you'd still need a database to store the refresh tokens. This is what GP was referring too.

> using JWTs in cookies is a win because you don’t have to fuss with storing session data on the server.

This is the author's claim, but the code clearly DOES store data on the server, for the refresh token.

Using JWT for "simplicity" is unfortunately common mistake. With JWT you can choose between simple (no storage required, no token revocation) and secure (immediate or delayed session revocation at the price of requiring storage). You cannot have both. OP chose security (by using a refresh token database), but this is no longer a simple solution. If you've already deployed a DB, Session IDs would always be simpler:

1. You could remove the refresh and redirect logic entirely.

2. You would only need one type of cookie.

3. You can remove dependency on JWT libraries, choosing the right cryptographic algorithm and configuring (and securing!) JWT signing keys.

This comes at no cost, since the refresh token DB is already there.

There can be good reasons to use JWT (although there are better standards out there for stateless tokens[1]), but simplicity is not one of them. Stateless tokens can be useful in the following cases:

1. Performance (increasing throughput or reducing latency by skipping the database for most calls).

2. Reliable cross-regional tokens (you don't need to replicate session IDs across regions and suffer from inconsistencies during failovers).

3. Decentralized verification (without relying on a central database).

4. Offline attenuation without network calls (with Macaroons or Biscuits only).

Unfortunately it seems like in 99% of the cases JWT is chosen as the access token format, it's chosen by its perceived simplicity and popularity, and the result is either a toy implementation that doesn't support token revocation, or an implementation that is more complex than it would have been with classic Session IDs.

[1] https://fly.io/docs/security/tokens/

[mattrighetti]

I agree with the overall JWT statements you made.

> This is the author's claim, but the code clearly DOES store data on the server, for the refresh token.

You're right, but I was making a different point about session IDs versus JWTs.

With session ids, each user request requires a server-side lookup to validate the session. For that reason, their ideal place would be something in-memory and that's what I was referring to with "data on the server".

While storing session IDs in a database is an option, in my case it would introduce noticeable latency because I self-host my projects on a cluster of Pis at home and even though I have a fast connection, a roundtrip to my external (I don't self-host it) database still takes a few milliseconds under low load.

JWTs allow me to avoid frequent server-side lookups. I can trust the client's data without hitting the database, except when issuing a new JWT - but even then, that happens every 2-3 minutes per user. While verifying JWT signatures and decoding claims does consume some CPU cycles, this overhead is minimal on my setup compared to the latency of database roundtrips.

Nothing against session ids, but I feel JWTs are better suited for my resource constrained setup.

[maz1b]

1. What if you store the JTI in your database and have the ability to immediately mark them as invalid, thus so that the next user request makes them logged out?

2. Storing just the JWT and things like user id should not be that big of deal for user performance. If you're refering to for example Apple sending massive jwt payloads for their IAP service, then i can see what you mean.

3. A standard has broken algorithms? This is news to me.

4. Don't most apps have databases? I don't see why this is a bad thing.

If JWT in httponly cookies are bad, what do you suggest inplace of it? For companies running multiple mobile + web apps

[VWWHFSfQ]

The major benefit of this approach is that you can avoid a database lookup when you have a valid JWT available. Only in cases where it's missing or expired would you need to hit the database for a refresh token.

This might not matter for trivial apps, but for very high-concurrency web apps this will matter a lot.

[0x457]

Sure, but unless you're near Google scale, you probably shouldn't worry about that. IMO JWTs should not be used on public internet.

[VWWHFSfQ]

> unless you're near Google scale, you probably shouldn't worry about that

Even just a few million concurrent users on the website can cause a huge amount of load on the database just looking up sessions over and over again.

[0x457]

Yes, that's why long time ago we figured out how to store those in some extremely fast memory store like memcached or redis. I hope people that work at scale where it's not a viable option don't need to read such blog posts to set this up.

To store 1M sessions, let's say each is 2 KB, you going to need 2GB. Somewhere around 15K session look ups per second will saturate the server (+/- 5K ops/s depending on the CPU) . If you want more sessions - use more RAM, if you want more ops/s - use more servers (cache cluster).

Another reason to JWT - cross-region authentication (replicating giant session store across the globe isn't a viable option)