Disclaimer: I’m a maintainer of a JWT library

The usefulness of JWTs and the stateful vs stateless approach is a somewhat heated debate on many communities… I think most of the time people are not comparing apples to apples.

When we say a JWT can be the same thing as a cookie there are many things that are not being taken into account IMHO. First of all, JWTs are one of many specifications in the JOSE umbrella (not José Valim, but JavaScript Object Signing and Encryption specifications). So, in reality it can be either a JWS (a signed token) or a JWE (an encrypted token).

Most of the time people who are for using cookies instead of JWTs are thinking only of signed tokens. More than that: people are thinking about tokens signed with symmetric encryption (a secret key that only the issuer of the token knows about it). This is not the best use case for JWTs and I agree with all the folks here about it. Cookies have better security if all you want is a session id (they can be set to be HTTPS only and with that no JS will reach it - in theory).

Where it shines, though, is when you have a setup with asymmetric encryption (public/private key pairs). I will not say this is more or less common. It seems most people here do their own authentication and are fine with it. In my experience, most corps rely on a centralized user storage with identity brokering, federation and what not… On this scenario you don’t have the user credentials and that is a good thing because your liability is different than when you have to store user credentials.

With asymmetric encryption (and signing) you can receive a token that you are not the issuer and still verify its authenticity by using the issuer’s public key which is, well, public. Many authentication schemes use this like OAuth2 with OpenID. Google, Microsoft and then some are using this scheme.

Another area where JWTs (and all the other JOSE specs) might be helpful is on standard encryption mechanisms and libraries. Cryptography is a tricky thing that most people don’t like to study ir. So, if you have to perform something like payload encryption, using JWEs might be a lot easier and safer than rolling your own encryption protocol (do not do that please…). One place where I’ve seen this being implemented is, for example, webhooks. You must ensure they are signed and encrypted to avoid tampering, miss authentication and so on. That is where most people get it wrong having to decide block ciphers, padding schemes, modes of operation and so on.

Well, you could simply turn your payload into a signed JWT (JWS) and then encrypt it with a public key of the receiver into another JWT (JWE). What is cool about this is that almost every language has a library for JWS and JWEs. It eases the “cryptography” burden for integration.

Of course you should still know what you are doing. These specifications have wrong interpretations, updates and so on. Signed JWTs, for example, used to pass which algorithm it used to sign it on the header. Some people simply passed the “none” algorithm and many libraries accepted that by default. This is just one example but there are others…

So, in conclusion, I see the JWT, JWS, JWE, JWA (JSON Web Algorithms), JWK (JSON Web Keys), JWKS (JSON Web Key Set) and extended specifications (like using Edwards Curve for signing/encryption) as a tool that can be used in many scenarios. The one of holding a “session” might be a good fit or not depending on your requirements.

For all that, I simply don’t agree with the sentence “JWTs are a solution looking for a problem”.

Anyway, I deviated too much from the discussion. Sorry for that!

is this the only way to invalidate the tokens ?

JWT are stateless. So you need a way to keep track of it.

So yes this general solution of keeping state is the only way.

The only good solution for JWT after help from this community and trying various libraries of login is API stuff. If you need user to login from a browser I would recommend the wonderful library POW.

This sounds almost like using sessions ?

Because it is. JWT is terrible choice for user session management.

Just use plain old cookie with session ID and call it a day.