> Now, let’s assume you are not Google. Check which of these apply to you:

> You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request.

A JWT is like a keycard. If a hotel gives you a keycard to access your room, the card itself holds the credentials which give you access to the room. That's the core principle behind JWT.

If you want to ban someone due to malicious conduct, then you need some kind of ban mechanism but this is a concern of spam prevention and attack mitigation. You need such mechanism regardless of what session mechanism you use. With JWT, you may need to do 1 lookup to check the account object (you can keep an isBanned flag on the account itself), with regular session IDs, you need 2 lookups (1 for the account object and 1 for the session object). JWT still saves you 1 lookup... Also, if gives you a lot of flexibility. For example, you may be able to keep a 'blacklist' in-memory and separate for each worker (that may be appropriate for certain use cases); you're not necessarily forced to hit a datastore or database as claimed. Banning and spam prevention should be seen as a separate concern.

Also, at small scale, there are scenarios where you don't even need a blacklist. Maybe your app is being served on an internal private network or maybe it's public but it's not so critical that you can't wait for 10 minutes or 1 hour (or whatever) for the JWT to expire for the ban to take effect. I mean, with the physical hotel scenario as an example; your keycard remains active until it expires. There are many such scenarios in the software industry where a ban doesn't need to take effect immediately.

When you need instant blocking for DDoS protection (where immediacy of the ban/block really matters), you typically rely on IPs, not specific account or session IDs.

> You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request.

As above.

> You need additional relationships between the user object and other objects in the database. You hit the database on each request.

The number of times you hit the database (and the reason for each lookup) matters and it's important not to mix up different concerns.

> Your service does anything at all with data in the database. You hit the database on each request.

This is just a variation which has the same flaws as previous arguments.

The author claims that Session IDs provide:

> Greatly reduced complexity. No need to manage a secure jwt signing/authentication key

You can provide the auth key as an environment variable when you launch the service. This is well supported in all environments at any scale including Docker, Kubernetes... anyway, 99% of services rely on various secrets like API keys so you need to pass secrets as env vars anyway, what's the issue with having just one more env var to hold the JWT signing auth key? There is no added complexity there as the mechanism for handling such secrets already exists in most applications. It's rare to see an application which doesn't have secret API keys... You need them for payments (e.g. Stripe API), for database API services (e.g. MongoDB cloud), Amazon AWS, etc...

On the other hand, managing sessions on the back end requires weird workarounds like setting and constantly refreshing expiries on the session keys or running complex cleanup cron jobs because you end up with complicated situations where your worker might crash and leave behind stale sessions. Session IDs are much more complicated.

Not to mention that session lookups becomes a single point of failure and can become a bottleneck for your application as you get more users. It's really difficult to scale well. You're going to run a Redis cluster just to manage sessions? Hello LATENCY!!! Welcome DDoS headache!!! Did anyone say backpressure issues??? How are you going to clean up stale sessions when a worker crashes? Good luck.

I hope you're billing for your development work by the hour, coz you're gonna need a lot of those! I hope your health insurer covers Panadol! Don't be surprised when GlaxoSmithKline opens up a new factory next to your office.