If you want, however, we can simulate the scenario. Find your JWT token, change your password (commonly invalidates tokens aswell), and then post it here post-invalidation. If it works still, then thats the issue. Though, changing your password commonly requires your current password and not just a cookie, so I wouldn't be able to do that. But I could probably change your username as proof. If it doesn't work, then it was checked against some revocation database that the article talks about, where at that point, where you have you check a database anyway, you might as well just store the session on the server, since the JWT is no longer stateless and provides no advantage over typical sessions.

It can be done right, but it's harder than doing something else. Take it like this: IF YOU KNOW WHAT YOU ARE DOING, OK, FINE, GOOD LUCK IF YOU DONT, STICK TO SOMETHING SIMPLER.

Simple solutions are better solutions, and developer time is important. Do you want to maintain simple authentication layer or you want this complex machinery, upgrade library, check for CVE, validate the library implementation, read the RFC. At that point I would be like... NO, I wanna go and do other things I'm interested in.