Wow, I found this to be a naive view of JWT usage. I'm not advocating it's usage for every circumstance, and, the author does add the disclaimer that he knows little about it, but I feel the author misses a number of basic concepts of JWT's. Here are some observations:

1. you are able to decode the headers and payload of the token regardless of what algorithm was used. This is because both are base64 values of the content they represent. The purpose of the JWT is to securely identify a user in a stateless environment. The token's use is therefore to pass basic user information (as well as token information for purposes of identifying how to decrypt the token, it's validity time, etc) along, while identifying the user at the same time. The former requires that data be easily readable, hence the base64 hashing of that content. The latter part is achieved by using an algorithm that generates the signature of the token using the first 2 parts and by providing a secret key. If the data in the token is modified in any way, the signature won't match. Hence the validation of the token fails.

2. You should never be including any sensitive data in the payload of the token. Such as password hashes. The example given in the post is akin to a developer storing a users sensitive details in a cookie. You could probably get away with "higher sensitivity" data stored in cookies in certain cases, but overall it's just wrong and as a developer one should know better.

3. Persistence of tokens is typically an issue admittedly. How I've typically countered such things is using shorter token lifespans, as well as such things as the inclusion of a "session" key on my users table. This doesn't prevent a db lookup, but the value of which can also be saved to a redis instance for example. The value of this field remains mostly static and can initially be the same across all users for example, and the value of which is included in the token payload itself. For example, all users can have the same value of 1 (very simple case, but bear with me). Now, if you need to invalidate a user session for some reason, or log them out of all their devices, or some similar action, simply change the value of this field. Your token validation would need to include a check against this value as well which makes this not very different to session storage (or rather a user cache) , but it's not a worse performance than server session storage and because the value remains mostly the same, is actually easier to implement in my opinion.

4. A single key used to sign all user tokens is generally a bad idea to begin with regardless... but that's like not salting passwords or taking any proper measures when securing users. The case mentioned in the post could be likened to someone accidently typing out an admin password for a web login in a public forum... in which case, shit happens. Sure, in such case it's easy to update the password without affecting user logins, but to be fair, the use of insecure methods for security in general rarely if ever leads to secure implementations. Can't expect a sturdy wall if you don't plaster the bricks together. So related to my point 3 above, use of the user's password hash, for example, or some other, non public, identifier in addition to the signing key helps tons. Or use an RSA implementation signing algorithm. If however, you want HMAC, or such, your performance using a user cache is not unlike server side session storage, and is easier to implement and maintain. All the while keeping the benefits of JWT.

Again, not for every use case, but it's not as broken or insecure as the post makes it out to be.