> 1. If someone gets access to your token [after you're logged out] they can continue to access it until it expires.
The author goes on to say that "security is binary — either it’s secure or it’s not". So... Is the token secure, or is it not?
If we can't assume that we have the capability to transmit and securely clear a string from the client, the whole discussion becomes somewhat pointless because both methods of authentication are borked.
> 2. Blocking users doesn’t immediately block them.
If you want to block a user, why would you block the JWT? Block the userId, or some other identifier that isn't coupled to a transient authentication mechanism.
> 3. Could have stale data. Imagine the user is an admin and got demoted to a regular user with fewer permissions. . .
This example demonstrates that this would not be good information to store in a JWT and blindly trust. Store a user identifier (or another immutable and unique identifier) and look up their permissions with that.
> 4. JWT’s are often not encrypted so anyone able to perform a man-in-the-middle attack and sniff the JWT now has your authentication credentials.
Encrypting the token doesn't make it harder or easier to sniff a token or to re-use it. Assuming the author isn't suggesting that people are transmitting literal account credentials unencrypted, this is the same point as #1 above because encryption and signing are meant to prevent against other attacks.