To use guardian db or not?

Hello there !

In the application I am working on we have a user status in the user schema. If a user is marked as inactive , the user won’t be allowed to login. Now we have a requirment where in, as soon as a user is marked as inactive, we also want to force logout the user ( revoking the jwt ).
from what I have read , one can use the module to store active tokens and delete the same once we want to invalidate the token…

This sounds almost like using sessions ?
to be clear the library indeed says that if you are considering using it, you have to rethink about authorization .

is this the only way to invalidate the tokens ?

Do you use JWT for access token? Then how do you handle logout currently?

If you always look up access tokens when authenticating a request - then you can revoke all access tokens by removing them from the table. (whitelist approach)

If you only check JWT - then you have to implement blacklist, since JWT will be valid until it expires. Search “jwt logout” :slightly_smiling_face:


  • Both requires some state stored somewhere.
  • Seems like guardian_db implements the first approach (whitelist) - keep the all issued tokens in the database.

The real question guardian_db asks is: whether to “revoke” JWT or not. If you’re not required to invalidate issued JWT, then you may just keep the JWT expires, and asks clients not to use it anymore. It solves most cases. However, in some cases… you may be required to implement strictly “revoke” the issued token. In that case, you have to do either whiltelist or blacklist.


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.


looks like a sane thing to do.
but this is primarily an API and would need to “stateless” .

If it requires guardian_db (and I assume has log-in feature) then it is not stateless.

1 Like

mhm. got it !
if I store an API token for a user, is it considered stateless or not ?

If you store anything, such as revocation or validity, then it is not stateless since there is state.

Don’t use JWT/Guardian for stateful services. In general you should not use it at all unless you specifically require JWT for some reason (which is basically never).


Hmmmm… you store state of the user session, answer this question for yourself. I will just say that in reality there is very few truly stateless services, and in most cases you have stateful services.


I keep thinking JWT is a solution in search of a problem - maybe useful for giving a client access to a service - but for front end authentication? Seems a bit much… Would love to know what the advantage is over a token and a session. Or is it just that the front-end frameworks decided this would be how the world works and we all just have to jump to their tune?

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.


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.

Yes and no, it depends :wink:

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.


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 :slight_smile:

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!