To be more explicit:
JWT is used for stateless service access. Like it is a token that is valid for, say, 5 minutes to access an image on a remote object store service, generated so that the client itself can hold on to it and pass it along without those two servers ever needing to communicate.
No you do not need to keep track of it. If you keep track then you use stateful JWT, which removes all niceties of JWT.
How do you reject a token without keeping track of it?
The original question was is this the only way to invalidate tokens. JWT are stateless. I thought the only solution to this is to keep track of the token to invalidate it.
Just like in @OvermindDL1 example. If you use JWT as a “one time token” then you just make them expire fairly quickly.
JWT itself is not stateful or stateless, it all depend on the way you use them. And if you need to keep track of all invalidated tokens then you have stateful JWTs. That is simple as that.
Just like in @OvermindDL1 example. If you use JWT as a “one time token” then you just make them expire fairly quickly.
I’m going to respectfully disagree with you that this type of action count as rejection or invalidating.
The guardian doc also imply using database for certain actions including this.
JWT itself is not stateful or stateless, it all depend on the way you use them. And if you need to keep track of all invalidated tokens then you have stateful JWTs. That is simple as that.
I’m also going to respectfully disagree with you on this. From my understand JWT are described as stateless because of how it is authenticated.
At least under the wiki article this is how JWT are described as when using stateless.
Morning!
I think what @hauleth& co. mean that it becomes stateful if you save it to the database and then add like a “revoked” column or something because that adds “mutable” state to it instead of just handing it off and be done with it.
As for valid JWT use cases, here’s where we used it:
Basically we had a separate (elixir) tracking service. That service needed to know whether you were allowed to push or read locations and for which courier_id. So the “main application” created JWTs encoding for which courier_ids you had what access rights. Both the web frontend and the courier app could then just present this token to the service and be done with it.
There was no invalidation or something, we set the expiry to 30 minutes or something so then the client would have to request a new one. That was fine (imo) as the attack vector for pushing or reading locations for such a limited time isn’t that scary.
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!
