I'm sorry I fail to see the difference between a cookie holding a server session ID and a cookie holding a JWT token. JWT sessions are created and stored (in some way) in the DB anyway and it's short lived. That's basically a session stored in a DB. When we say no to sessions we only mean server sessions in your backend service as this can't scale horizontally. I feel like this is just a shiny title confusing different approaches and practices.
Agree, snippet is conflating a lot of things.
JWT is a signed JSON blob.
Cookie is a storage and transport specification.
Local storage is a storage spec.
A "regular" cookie could also be a signed cookie which is basically the same thing as JWT.
Slight disagree in horizontal scalability--server sessions scale somewhat with Redis, replicated DB but obviously not to the degree stateless ones do.
Also on revocability, you don't need to revoke the token if you're validating fine grain permissions outside the token. You can revoke the permissions (ie disable the user). You can use JWT to gate permissions at a high level (infrastructure, traffic edge, API gateway) then validate fine grained permissions in code
JWTs aren't stored in a backend though.
Session cookies you exchange an opaque value with the DB for the user info
JWTs the user hands you their driver's license, and you can verify that it's an authentic license for the person who's name is on it
The word "session" is overloaded. In browser terminology, a session cookie is one that expires/is cleared when you exit the browser (it doesn't persist on disk)
In application terminology, a session is user state that outlives a single request.
Depending on what definition you use and how pedantic you are, a stateless signed cookie is also a session cookie.