That being said, always going to the database for connecting an opaque session token to an identity can quickly become slow, and if those features listed above are not desirable, having a blocklist of revoked JWT IDs in an in-memory cache (like Redis) can bring back some performance benefits.
Still very few companies need something like this.
PHP does this every single request. I’ve never had enough users that this became a significant issue (and you probably don’t either)
Doing this obviates some of the benefits of JWT's statelessness, but for situations where revocation is really important and you can't have that few seconds of JWT validity after a user logs out, this totally works.
My employer has an article about this topic here: https://fusionauth.io/learn/expert-advice/tokens/revoking-jw...
with JWTs you have the flexibility with the opaque you don't.
JWTs also allow you to do client-side logic on things like entitlements but then verify against database when the user tries to view something
If select by id or token is slow for you then I worry about the rest of the application quality. Probably much slower elsewhere that the identity lookup is the least of your concern.
A few reasons why you might want the opaque token come to mind:
* You want the OAuth ecosystem (the libraries, the scopes, the user permissioning)
* You are being forced to use an opaque token because your user authenticates somewhere else, and they only provide you an opaque token.
This is where a identity service also can help ;-)
Surely you could trust a signature and lifetime but that makes the cookie no different than a JWT (only storage wise the differ in that case).
Generally speaking it is recommended to use opaque tokens and rely on the userinfo / introspect endpoint call to make for the session management.
Only in specific cases where latency and/or scaling might become an issue you should opt for JWT. At least this is my opinion.
I think that is the point of the op: If you have to check a db to realize revocation, then you can use session cookies because they also need to hit the db. (Because you don't get rid of the db hit for using jwt).
As a rule, there is no difference. But if you are one of the exceptions, those can have differences of orders of magnitude.
You normally do lots of API requests while you are logged in. To services and to download an image for example.
You make sure the current jwt is valid for a few minutes and hit only the database with the refresh token for example.
Only in worst case you really need to block a token and it might be much easier to sync those few tokens in your system into some local cache and let them expire automatically (because you know when they expire as it is contained in the token).
But yes if all of this sounds complicated, use sessions and a distributed redis for your session or just the database.