Email -> Magic Link Login 🔗

[nelsonic]

As noted by @ndrean in dwyl/learn-postgresql#84 (comment) 💬
We don't currently have the concept of Magic Links in this project. 🪄
My reasoning was that we don't want people clicking links in email because it promotes Phising ... 🙄
But we do already have email verification.
e.g: templates/verify.txt#L6-L7

Todo

• Gage the demand from other people in the community for this feature before adding it. Might be that we only consider it as part of the re-build with gen.auth phx.gen.auth ? #133 -> Proposal: Rebuild Auth App using mix phx.gen.auth when [email protected] Ships #207

P.S: Just tried the email send function and it still all works. 🤯

I probably shouldn't be surprised because nothing has changed and it worked fine last time I checked ... ⏳ 💭 😜

[iteles]

As a technical tool, I love magic links. They're very cool.

As a layman user of apps I personally am not a fan of magic links as I have seen them historically implemented from UX perspective. I used to use them back in my slack days (4 years ago) and they were cool the first time, annoying the rest.

I'm annoyed by having to go back to my email when trying to log into an app and especially so when I have to request magic links for multiple different devices (usually they expire after one click) and having to do this process continually across all devices when the login expires after a few months is frustrating.

I already have password management in place (and these days, most people do in their browsers anyway) and this messes with that system.

I also can never remember which email address I signed up to something with but this could still be managed by the password manager so is less of an issue.

Interested to see if I'm in the minority and magic links are all the rage!

[nelsonic]

@iteles I feel that Magic Links are a UX-bandaid 🩹 more than a long-term solution to the auth challenge. 💭
We've chosen to focus on OAuth Providers [Google and GitHub] for now as the easiest/fastest way to authenticate. 🚀
I think that if we add Microsoft Auth dwyl/elixir-auth-microsoft#1 we will have all the bases covered from a [corporate] OAuth perspective ...
95% of people have a Google or Microsoft Account.
Then if we add Sign in with Apple #37 🍏 we will reach 99% of people with mobile devices. 💯
My hunch is that very few people will opt to use an email address to authenticate. 📉
And those people might not be our "target customers" for the App ... 🤷‍♂️

But this issue is open for feedback and if enough people [that will pay to use the App] want it, we can build it. 👌

[ndrean]

For mobile devices, I heard that 3/4 of people don't have an email address .... so depends on your target. Indeed, OAuth is the way to go I believe, but one giant is missing, Facebook. I looked at it the other day and did not completely understand nor had the patience to implement the server-side process🙄. If you are interested, I will try it asap.

[nelsonic]

We are keen on helping people migrate off Facebook (eventually) once our App has a few more features.
But we haven't even listed them on the roadmap yet, because we're avoiding distracting ourselves with "social" features ...
If you want to take a look at this: dwyl/elixir-auth-facebook#21 👀

Otherwise let's keep the discussion of this thread specific to Magic Links. 🔗 🪄 👌

[ndrean]

You are wise🤔. I believe passwordless is straightforward: a signed token based on a user_id (new_or_create) which is saved with "pending" status and on reception to an endpoint, the query string contains a token and is verified for the signature and decoded and a lookup at the user_id to check for the token, and if ok, generate a new one, save it and pass status "confirmed". I made something like this for my little app.

[ndrean]

Do you permit links as function components?

[nelsonic]

Was recently reminded of the "right" way of doing email verification
while I was setting up Plausible/Analytics: dwyl/technology-stack#127

This is the approach we will be taking.
Yes, there is an extra step; copy-pasting or manually typing the verification code.
It not only feels more secure to the person verifying their account, it is more secure.
This is one of the few instances where the UX is improved by having an extra step.

"Never click links in email" ~ https://www.kaspersky.com/resource-center/preemptive-safety/phishing-prevention-tips

[ndrean]

You may be right about these evil links.🙄 At this moment, I have plenty of fake emails with links to follow coming from fake accounts such as DHL, UPS etc...

Sending a code via email makes the code slimmer compared to the magic link; you don't have the extra endpoint with the URL parsing step. You only need to insert a tuple "email, code_sent" into the DB and store the active email in the session, don't you? How does this work for mobile where you don't have a session?

[ndrean]

Passkeys:
https://developers.google.com/identity/passkeys/supported-environments
https://developer.apple.com/passkeys/

Probably something to watch: https://hexdocs.pm/webauthn_components/readme.html

[nelsonic]

Definitely. One to watch. https://webauthn.guide

[ndrean]

[nelsonic]

Yeah, watched that a while back. still very much "beta" though ...
I'm very much of a "Wait and see if it becomes mainstream" when it comes to auth systems now.
Glad someone else is doing work to innovate in the space.
But ultimately use OAuth 90%+ of the time.