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.
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)
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.
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.
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.
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."