“Passwordless” Logins allow user to login with only their email address. After providing their email address, they receive an email with a “magic link” (a URL with a sign-in token as parameter). They click on the magic link, get redirected to the login page and are henceforth successfully logged in. The login tokens are typically valid for 15min and can only be used once.
My team an I wrote a library based on the popular Ueberauth framework that handles the whole authentication flow for you. It is called ueberauth_passwordless and you can find it on GitHub. I hope the docs explain well enough how to get started.
It uses Ueberauth’s handle_request! function to create and send the magic links to the user. A custom module must be defined which sends the actual email. You can use any mailing framework you want (I prefer Bamboo though for its testability). When a user clicks on the magic link, the handle_callback! function handles the verification of the token. The library gives you full control over what happens after the verification. My main goal was to keep the library flexible and customizable so that you can integrate it into your system according to your needs.
Any feedback or improvement suggestions are more than welcome 
Previous Work and Gratitude
I’d like to thank @zanderxyz for his Veil library. It helped me a lot with getting started. I decided against using the Veil library though since I didn’t want to have extra DB Schemas and some more control over the whole authentication flow. Also, this repo helped me a lot to understand implement a custom Ueberauth authentication flow.
3 Likes
While :ets sounds great to not depends on a database this essentially means a redeploy or any other restart of your system makes any tokens invalid.
The login tokens … can only be used once.
I’d be cautious with limitations like those. There might be automated systems like spam filters checking links in emails, which would then make the link useless to the actual user.
3 Likes
While :ets sounds great to not depends on a database this essentially means a redeploy or any other restart of your system makes any tokens invalid.
You’re exactly right. That’s why the :ets store is optional and can easily be en/disabled. In our project, we chose a Ecto-based store for the tokens instead, but if you have a 0-downtime environment, the ets-store might come in handy.
I’d be cautious with limitations like those. There might be automated systems like spam filters checking links in emails, which would then make the link useless to the actual user.
Hmm, that’s a very good point actually. I’ll check whether that’s a problem to us and will fix it accordingly. Thank you very much for the input!
1 Like
FYI, this is done already:
That does email login, using only guardian, not even using ueberauth, not storing in ETS or ecto. Basically you can store everything (uid, claim, time limit) inside the token, encrypted and temperproof.
That module is so small I end up just cut and paste the few lines that really matters.
2 Likes
Yes, thank you for pointing that out. I looked at this library as well during my research, but since we use Ueberauth at work, a solution should have been based on that library instead of Guardian since we didn’t want to pull in another large dependency. However, if you use Guardian, I agree that this library would probably be more suitable for your needs.
Ueberauth and guardian are from the same author and work nicely together.
I use both; I use ueberauth for oauth login, and guardian for maintain user’s identity throughout the session.
To quote ueberauth’s doc:
ueberauth
Ueberauth provides only the initial authentication challenge, (initial OAuth flow, collecting the information from a login form, etc). It does not authenticate each request, that’s up to your application. You could issue a token or put the result into a session for your applications needs. Libraries like Guardian can help you with that aspect of authentication.
1 Like
