Have you had a look at guardian_db? It has a process GuardianDb.ExpiredSweeper which is meant to clean your expired tokens after x num of minutes as specified in the configuration. I couldn’t get it to work (I have a feeling it was something in my config) so I am trying to set up OpenMaize.

Looking for a solid solution as well…

I’ve looked a bit at guardian_db but not that much yet.

But if I use JWTs, which are supposed to be self contained and can be cryptographically verified, then I store them in my DB and must verify that they are present there as well, and on top of that adding the complexity of a sweeper to clean it out…isn’t that defeating the whole purpose of using JWTs? What is the difference in doing that and just store a simple random string instead in the DB with an expiration date?

The more I read about JWT it feels like people have started to use them for the wrong things. Really, they should be used with a relatively short expire time and not for people to authenticate, over longer periods of time, from something like a mobile app.

What would be a good use case for a JWT (as far as I understand)?

• Confirm email token/reset password token (could be valid for a few days)
• Download token to get access to download a file (valid for a few minutes/an hour)
• Between your own servers (think microservices)

But maybe I’m wrong?

I am grappling with the same issue as well. I am almost going the Whatsapp way.. no logout.

With JWT perhaps, you could store signing key within your model and issue different tokens with different expiration time(they all gonna be valid for a particular user and contain information for your business logic). Then you can revoke user key without affecting others.
Or issue tokens with short expiry time and renew each time until you see appropriate to stop(e.g. user was inactive a week)

But if you store a signing key in the DB, you need to fetch that for each request. Why not just fetch the token then? What’s the upside of using it?

With just a random string as a token you can just fetch it from the DB (instead of fetching the signing key). Sure, a JWT has built in expiration, but is it worth all the complexity to just avoid adding a datetime field in the DB?

Another thing I’ve been thinking about: When the user changes his/her password it would be nice to invalidate all the user specific tokens. Would it be OK to us the password hash as a salt/signing key? That would automatically invalidate the tokens when the password changes.

This doesn’t work in all situations, but consider that one of the strengths of BEAM is managing state in processes. Why not load the key from the database and keep it in a GenServer’s state, or even just ETS? No need to make the round trip to the DB, and when you write a new key you just kill the old process and let it reload itself from the (now updated) db record.

With this I believe you might not even need a db. Your GenServer is your key store.

I have to say that’s a pretty smart way of looking at it. So all you need to do is create a key for the PID then when the user signs out (Guardian.revoke) You simply call to kill the process?

If all you’re doing is storing the session token, I’d probably reach for ETS first. If you’ve already got a per-user process going (and its truly account-related, not something where you’d just be tacking on some random piece of info) then I’d look at making it a part of that state. But I’d probably still echo it out to a database unless you’re ok with everyone’s session dying when you do a deploy or restart your node for whatever reason, and you’re also ok with the complications that will arise from needing to do session lookup in a cluster (assuming you want to run more than one node in production.)

I don’t want to trivialize the function; session management is one of those things that gets real complicated real fast at the edges. And frankly I’m new enough at this ecosystem that I’d want to have someone more experienced weigh in on what would be idiomatic and proper. But do keep in mind what the draw for BEAM is in the first place: excellent concurrency and state management tools that go far beyond just a record in a database somewhere.

I may have missed something while I was looking into JWTs but here are some reasons why I decided to go with them:

JWTs contain information about the user, to include access rights. You can decode the JWT to see if that user should have access to a specific API route rather than hit the DB for that info.

I’m sure you’ve referenced it, but I found this article helpful in evaluating the use of JWTs. There’s information in there about high security use. https://stormpath.com/blog/build-secure-user-interfaces-using-jwts

I was recently given a link to an article, which perfectly summarises my thoughts on JWT: Stop using JWT for sessions - joepie91's Ramblings