dwyl / auth

πŸšͺ πŸ” UX-focussed Turnkey Authentication Solution for Web Apps/APIs (Documented, Tested & Maintained)
https://authdemo.fly.dev
GNU General Public License v2.0
127 stars 9 forks source link

Email -> Magic Link Login πŸ”— #223

Open nelsonic opened 1 year ago

nelsonic commented 1 year ago

As noted by @ndrean in https://github.com/dwyl/learn-postgresql/issues/84#issuecomment-1277916838 πŸ’¬ 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

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

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

iteles commented 1 year ago

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 commented 1 year ago

@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 https://github.com/dwyl/elixir-auth-microsoft/issues/1 we will have all the bases covered from a [corporate] OAuth perspective ... :shipit: 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 commented 1 year ago

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 commented 1 year ago

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: https://github.com/dwyl/elixir-auth-facebook/issues/21 πŸ‘€

Otherwise let's keep the discussion of this thread specific to Magic Links. πŸ”— πŸͺ„ πŸ‘Œ

ndrean commented 1 year ago

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 commented 1 year ago

Do you permit links as function components?

nelsonic commented 1 year ago

Was recently reminded of the "right" way of doing email verification while I was setting up Plausible/Analytics: https://github.com/dwyl/technology-stack/issues/127 image

image

image

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 commented 1 year ago

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 commented 1 year ago

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

Screenshot 2023-02-15 at 09 46 04
nelsonic commented 1 year ago

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

ndrean commented 1 year ago

Screenshot 2023-02-15 at 12 51 44

nelsonic commented 1 year ago

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.