The author here seems to be arguing that you should effectively never use JWTs. That, in my opinion, is a mistake.
JWTs have absolutely been over-hyped for the last 8-10 years, but they do have a use and you don't have to be at the scale of Google for it to be the right approach.
Software isn't as simple as creating a checklist of a few basic categories and saying there is always a right or wrong answer. The answer should be "it depends" because there are many more factors at play when deciding something as fundamental as authentication and authorization.
JWTs has been both overhyped and overused, by myself as well. But after working with JWT authentication for so long, it felt very strange to go back to sessions stored in a database. Suddenly every service we have needs a db connection setup to go verify the sessions. No more stateless and authenticated services. But I still agree JWTs have been overused. One of the things I have used it for that I found the most useful is probably just storing some smaller pieces of signed state during parts of a data transfer, like just bridging between two systems or in-and-out of a browser without needing to setup a database.
I may not have been clear there. I'm not saying the author's list is wrong, I'm saying its incomplete.
For starters, the blog post leads with the premise that the answer is always "No". Even ignoring that as playful banter, the checklist is way to broad to be universally true.
> 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.
> 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.
> You need additional relationships between the user object and other objects in the database. You hit the database on each request.
> Your service does anything at all with data in the database. You hit the database on each request.
These all assume that I authorization data and that the user data lives in the same database. I may store my own user object with a unique ID that references an authenticated user, while the author flow is actually managed by an entirely different service (whether first party or third party). I also may have my user data stored in a separate database, say for legacy reasons or data security/integrity requirements. Not every database is crested equal, its totally possible that one database is a better fit for user data while a totally different database is needed for application data.
Coming up with a list of broad scenarios and claiming that if you check any one there is never a reason to pick JWTs over sessions is misguided and overly simplistic. Context always matters.
>These all assume that I authorization data and that the user data lives in the same database
Please tell us how the following assumes that authorization data and user data lives in the same database:
"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."
It doesn't have to assume that, again because context matters.
If authorization data is stored outside my database, I may not store anything related to that user other than their unique ID. I may not know anything about the JWTs because a middleware talking to the external authorization service authorizes a request before I ever query my database.
I could also store valid JWTs in my own database or in a caching layer, say with redis for quick access. There's nothing wrong with that, but without more details on what someone is building and what it needs to be designed for there is no absolute right or wrong answer.
I don't see how anything you said would refute OPs premise, that if you want proper logout [1] in your app, you can't use JWTs without constantly querying whether a particular JWT should be accepted or not, from which it follows that this query mechanism may as well be a traditional database with a "sessions" table.
How you organize your data, your services, your middleware, etc. does not change this the slightest, hence are irrelevant.
----
[1] proper logout is instant (this invalidates the "just use a JWT with short timeout!" argument), and prevents session stealing (this invalidates the "just throw away your JWT to logout" argument)
> may as well be a traditional database with a "sessions" table.
Isn't that kind of the point though? I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction.
If logout can work either way, and in all likelihood logout isn't a performance concern as long as its secure, you may have other use cases and requirements in an app that do make JWTs a better fit.
I still don't understand how the argument here can be that there are no cases for JWTs, or that the list of "its" in the original article can be bulletproof no matter what else is going on in a project. That's unnecessarily absolute and leaves no wiggle room for competing priorities and constraints.
>I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction.
Because the whole selling point of JWTs was that they eliminate this database transaction!!!
As soon as you have logout, your JWTs degrade to nothing but a unique byte sequence that you need to check in the DB whether it's still valid or not. You may as well use unique JPEGs or MP3 files to identify your sessions - it would work just as well (and it would be equally stupid).
In fact, in the presence of logout, JWTs are worse than opaque session tokens, because careless programmers developing a new microservice might see that it's a JWT and be tempted to just check the signature and the expiration without consulting the auth database for revocations, thus leaving that microservice accessible with compromised tokens.
Ah okay, so that was just the wrong selling point! JWTs can* avoid a database query if the data isn't super important, like if you just want to tack on some session context and aren't worried about invalidating it manually. Session tokens are just a unique ID, there is some value in wrapping up data inside the token like a JWT. That just isn't always suitable.
For authentication and authorization there isn't much benefit, but that doesn't make one right and one wrong. They can be useful in certain author scenarios, like if you're using an external author service.
If the argument here is simply that JWTs aren't a huge benefit in auth, sure that's fine. I just don't agree that that means they should never be used for auth or that they are universally worse for auth in all scenarios and applications.
Do you maintain a database of JWT session tokens for refresh and revoke?
Do you have a real session that you load for every user every request anyway?
If the answer is 'yes', then the answer to 'use JWT' isn't 'it depends'.
It's no.