jordiee
AccessPass - a opinionated authorization library
I spent the last couple weeks writing my own authorization library that provides all the basics like login,logout,register,forgot password,forgot username and email confirmation. I found myself re implementing auth every time I started a project because I did not quite like the options out there(hence why the lib is quite opinionated).
AccessPass is token based(kind of actually you send id’s in place of tokens) that is backed by a genserver for refresh tokens / access tokens.
This is my first hex package published so I would love some feedback.
The one thing left to do for me is write tests.
https://hexdocs.pm/access_pass/introduction.html
Thanks!
Most Liked
jordiee
jordiee
jordiee
0.5.6:
base_url added to config to override email href links for stuff like update password / confirm email.
login_return override added to allow for stuffing additional data in the default /login /register return.
Docs have been updated to be more accurate thanks to pull requests.
anandtrex
@jordiee AccessPass looks cool. I have been looking for an authentication library, and this one looks promising. I would be curious to read about how it’s opinionated – what aspects of exising auth libraries you have borrowed and which ones you didn’t like. On a different note, does it support JWT tokens?
jordiee
That is correct to some extent. I actually made some changes recently so that the primary storage is ETS but all writes to ets are serialized through a genserver. I did this so that doing access_token checks was not a bottleneck and getting serialized. As for losing all tokens when servers is restarted this is correct in that if the service is restarted or crashes all tokens will also go with it. If you do not want tokens to go when restarting the server maybe look into hot updates but as for crashes…when designing the system. I weighed out if it would be worth it to back up the ets table on crash but decided against it. I decided against it because something that leads to a crash…in all honesty is most likely a bug that needs to be fixed. The storage should not crash if it is bug free. So I would rather it crash and I/or some else put a pull request in to fix the bug.
As for having it backed by a db. I decided against this because speed was a huge concern for me. I have implemented auth systems before that stored tokens in a db and it was noticeable to have to hit a database on every call that is authorized. I ended up switching them to redis in the end but with elixir and ets it does not seem needed.
As for scaling horizontally right now you are correct in that it would be hard to do. I am potentially going to look into mnesia rather then ets to have a shared table of tokens. But for now if you are worried about scaling applications horizontally separate of AccessPass I suggest setting up a normal phoenix app and just having accesspass run on it. From their all of your services that need auth can delegate calls via http to your “auth server” as for authorizing individual routes this way you can use the /check endpoint in much of the same way the plug is used. The downside to doing it all this way is it is slower because it goes over the network but the pro is you can scale your application separate of accesspass







