Mmmm… that completely threw the spanner in my engine 
Quick query, what is the alternative, in Elixir world. What is the best bet when developing a phoenix powered api based mobile only app?
This link discusses the article you posted.
chu
Linuus
michalmuskala
I won’t tell you what’s best, because I don’t know myself Right now in our app we use simple bearer tokens - is that’s the best? I don’t know, it works for us right now.
I think JWT is fine, if you accept that it’s rather impossible for it to be truly stateless, if you want to be able to invalidate tokens, which is pretty much required for web/mobile apps.
4
andre1sk
If you use JWT you gain some flexibility, yes you will lose some features as noted above if you use it in stateless fashion (as intended), but at least you have that option should you need it due to some extreme load spike plus it’s fairly easy to have a separate store for tokens and you don’t need to hit db for the user/profile info.
2
riverrun
I maintain an authentication library called Openmaize, which is similar in some ways to Guardian.
About the concern about invalidating tokens on logout, I think Guardian might have some mechanism where they do a database lookup to check this (at least it did have this the last time I looked at Guardian). With Openmaize, I’m using a genserver to store invalidated (logged out) JWTs, and on authentication, the state in this genserver is checked before setting the current_user variable.
Regarding your point about short expiration time, with Openmaize, the default expiration time is two hours after being issued - is this too short / too long? This seems like another case where there is a trade-off between convenience and security, and the expiration time will also depend on how valuable the resources are that you are protecting.
3
chu
I have been looking at openmaize and liking it so far. I did take out bits and pieces that seem to focus on what I wanted and exchanged things like signup mail with Twilio based sms for the key. A lot of work seem to have gone into thinking this through, thanks a lot.
Having a go at openmaizejwt today.
For purposes of discussion, how solid it be to use something like eternal and plug this into token revocation and creation?
1
Linuus
I guess you store the invalidated tokens in some persistent storage as well, and not only in the gen server state? Otherwise you’d loose track of them at each deploy/restart. Also, having a blacklist of tokens seems odd to me since that requires you to keep them forever. Isn’t it better to just have a whitelist instead (which takes us back to regular tokens again )?
Regarding expiration time, it totally depends on your application. Is the token used for confirmation email/password reset? Keeping a user signed in? Different use cases would require different expiration times.
The problem (for me) is that it is the only way to invalidate JWTs whilst using them for their main benefit. What is their main benefit? In my opinion it is that you don’t have to store them anywhere, they can just be validated anyway. As soon as you must keep track of them, they loose their main value and you are probably using them wrongly.
3
swennemans
Currently I’m playing with the following idea:
- Generate a JWT that is short-lived, for example 5 minutes.
- When generating this token, store a random string (let’s call it auth_string) in the database.
- Also store this auth_string in the JWT.
- On every client-server communication, do the following:
– If the connection is within the five minute expiration time, just extend the expiration of the JWT with 5 minutes
– If the connection is outside the five minute expiration time, check the auth string of the user in the JWT and compare it with the auth_string in the database: if it’s the same extend five minutes. Otherwise: logout.
The auth string in the database will be changed on every, logout, password reset etc. Now you can invalidate users rather easily by changing the auth string. Unless someone is reconnecting every X minutes of course. if an user is active you don’t need to do any (expensive) database lookups.
Seems like an ok tradeoff.
Thoughts?
3
karmajunkie
Couple of thoughts:
- To extend the token, you’re going to have to change the
expclaim and generate a new token on each request, which means a client will have to support receiving and storing a new token on each request. Why not just use thejticlaim and produce a nonce on each request, which must be provided by the next request? - Given that your token lifetimes in this scheme are so short, why bother with the database? Use ETS or an existing per-account genserver to store the
auth_stringin your outline? - This will get a little more complicated if you allow for multiple active logins for a single account (e.g. mobile and web logged in and active at the same time.)
2
Linuus
In most cases, you’ll probably fetch the user from the database anyway, right? So, what’s the upside of this compared to just a raw token in the DB that you change on each logout/password reset etc?
The only upside I can see is that you don’t need to fetch the user for 5 minutes. Essentially you’ve built a cache
3