This article seems opinionated without much substance and I disagree with many of the points listed. It also doesn't address using a JWT Token in a Cookie for Web Apps as recommended at:
JWT's are simpler when your System is composed of multiple Services as only a single Service needs to issue JWT's and provide Auth Services, all other isolated Services only needs to know how to validate a token and doesn't need other Session State or Auth configured yet are still able to provide protected Services.
More flexible
JWT's allow for externalized, centralized Auth where the issuing of the Token can be decoupled from validating it. It lets you easily launch new Services offering Protected API's out-of-the-box without needing to configure any Auth or persistent Session state.
Data goes stale
Services that care about stale data embedded in JWT's should hit the DB using the UserId embedded in JWT's, this is more "live" then accessing it from a Session which is stale from the moment the Session or JWT is created.
More secure
It's not less secure, and one instance where it can be more Secure if you use RSA as the centralized Auth Service can sign JWT's with its private keys and Services validating tokens with only a public key. So JWT's can be cryptographically verified it's been issued from a central authority with access to the Private Key. Whereas authenticity of Session data is not verified and can be tampered with anyone with access to the session data store. The recommendation is to use Redis which offers weak security since it's not supposed to be accessed externally so uses a simple password which is sent plain-text over the wire.
Built-in expiration functionality
"This is nonsense, and not a useful feature." Unhelpful Opinionated assertion slinging. Embedded expiration could be a simple constant or implemented from a Custom policy based on the User. Since this is decided by the Issuer this logic only needs to exist in one place.
Works for users that block cookies
"Unlikely. Users don't just block cookies, they typically block all means of persistence." Not sure where the article gets its fact checking from, but this is another opinionated assertion not backed by any sources. Cookies are blocked due to privacy issues, whereas Local Storage is used a lot more for providing rich Web App functionality. Disabling Cookies definitely does not also imply disabling Local Storage.
They take up more space
The space trade-off is due to enabling a more performant, scalable and flexible stateless architecture.
You cannot invalidate JWT tokens
Another strong assertion that is false. You can include any mechanism you like to invalidate tokens, e.g. you could embed a unique JWT Id (https://tools.ietf.org/html/rfc7519#section-4.1.7) to check against a blacklist loaded in App Servers memory. Your JWT implementation could have an option to "Invalidate all JWT Tokens issued before certain date" which is similar to flushing a Session storage, i.e. all JWT/Sessions created get invalidated. The simplicity and statelessness of JWT's makes it easy to apply custom generic logic.
https://stormpath.com/blog/where-to-store-your-jwts-cookies-...
And ignores usage of refresh tokens: https://auth0.com/docs/refresh-token
JWT's are simpler when your System is composed of multiple Services as only a single Service needs to issue JWT's and provide Auth Services, all other isolated Services only needs to know how to validate a token and doesn't need other Session State or Auth configured yet are still able to provide protected Services. JWT's allow for externalized, centralized Auth where the issuing of the Token can be decoupled from validating it. It lets you easily launch new Services offering Protected API's out-of-the-box without needing to configure any Auth or persistent Session state. Services that care about stale data embedded in JWT's should hit the DB using the UserId embedded in JWT's, this is more "live" then accessing it from a Session which is stale from the moment the Session or JWT is created. It's not less secure, and one instance where it can be more Secure if you use RSA as the centralized Auth Service can sign JWT's with its private keys and Services validating tokens with only a public key. So JWT's can be cryptographically verified it's been issued from a central authority with access to the Private Key. Whereas authenticity of Session data is not verified and can be tampered with anyone with access to the session data store. The recommendation is to use Redis which offers weak security since it's not supposed to be accessed externally so uses a simple password which is sent plain-text over the wire. "This is nonsense, and not a useful feature." Unhelpful Opinionated assertion slinging. Embedded expiration could be a simple constant or implemented from a Custom policy based on the User. Since this is decided by the Issuer this logic only needs to exist in one place. "Unlikely. Users don't just block cookies, they typically block all means of persistence." Not sure where the article gets its fact checking from, but this is another opinionated assertion not backed by any sources. Cookies are blocked due to privacy issues, whereas Local Storage is used a lot more for providing rich Web App functionality. Disabling Cookies definitely does not also imply disabling Local Storage. The space trade-off is due to enabling a more performant, scalable and flexible stateless architecture. Another strong assertion that is false. You can include any mechanism you like to invalidate tokens, e.g. you could embed a unique JWT Id (https://tools.ietf.org/html/rfc7519#section-4.1.7) to check against a blacklist loaded in App Servers memory. Your JWT implementation could have an option to "Invalidate all JWT Tokens issued before certain date" which is similar to flushing a Session storage, i.e. all JWT/Sessions created get invalidated. The simplicity and statelessness of JWT's makes it easy to apply custom generic logic.