9 ms·

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a

by movedx 6y ago

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email address in the database. This has never happened. EDIT: "fault" => "problem"

eloff 6y ago
I had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email. Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where requests would be routed through different exit IP addresses in different regions for the same user. On top of that, 5 seconds later it would repeat a request. Not just GET requests either, but also POST requests. How they get by without horrible things happening is beyond me. This completely broke user sessions since any login attempt would be followed by a second login for the same user which invalidated the session token. Imagine trying to use your online bank with that network. If anyone has seen anything similar in the wild, I'd love to hear from you. We never figured out what software they have that does that. We changed how our sessions work to get around it, but it probably ranks as the most bizarre issue I've encountered in my 20 year career.
- pwdisswordfish4 6y ago
  > We changed how our sessions work to get around it In other words, you fixed the bugs in how your original implementation relied on bad assumptions that it shouldn't have tried to rely on to begin with. The only real quibble here might be that duplicate requests cost you unnecessary transit.
  - eloff 6y ago
    Duplicate POST requests are a violation of the HTTP standard because they are not assumed to be idempotent. I hope you're just misunderstanding the problem.
- schoolornot 6y ago
  Not that uncommon for large companies to bring their IP space in house to multihome and load-balance traffic across multiple providers. If they are routing traffic back to random data centers for centralized filtering, it makes sense how it could be coming from different regions. I'm more interested in what made your application sensitive to this. The duplicate packets does sound bizarre. Maybe a mirroring issue or firmware issue.
  - eloff 6y ago
    The changing ips were ok, it just made diagnosing the issue difficult in the logs. The duplicate requests (not at the packet level as TCP ignores duplicate packets) were the root cause of the issue.
    - mst 6y ago
      Reminds me of the "fun" of dealing with a RADIUS system that would, about 20% of the time, send me two START packets for the same session ... with different sequence numbers. This made successfully managing dynamic IP pool allocation on my end an ... interesting ... experience ;)
madjam002 6y ago
I have tried something similar, although I am encountering issues with people having to wait 10+ minutes for their codes at times, yet sometimes it arrives immediately, which is frustrating when it comes to login. I haven't spent any time debugging in depth yet, apart from looking at the email headers and seeing that it takes over 5 mins for the email to get from SES to Gmail. Not sure why!
- 542458 6y ago
  MXroute has a blogpost where he digs into this a bit. IIRC it actually gets accepted by Google immediately - but then spends 5mins in the ether inside Google before it hits a Gmail inbox. No way to tell what the delay is coming from, other than it appears to be out of our hands. Edit: https://mxroute.com/delayed-delivery-to-gmail/ https://mxroute.com/delayed-delivery-to-gmail/
sebmellen 6y ago
There's a great project called Portier [0], which does this quite nicely. I highly recommend it. It's a successor of sorts to the ill-fated Mozilla Persona project [1]. > Portier (pronounced "Por-tee-ay") is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password. [0]: https://portier.github.io/ https://portier.github.io/ [1]: https://en.wikipedia.org/wiki/Mozilla_Persona https://en.wikipedia.org/wiki/Mozilla_Persona
nickthemagicman 6y ago
This is a really cool idea. So they basically go to their email and verify and it stores a token in their cookies?
- movedx 6y ago
  Exactly. They login by just providing their email. It sens a link with a unique code in it. This code is checked against the DB and if it's correct, they get a cookie (the digital kind ;])
  - eps 6y ago
    Beware of setups that verify (i.e. visit) all links in an email upon receiving one. This completely breaks one-time use login links.
gfxgirl 6y ago
I know I'm the exception but as a privacy oriented user I hate this. There are services that try to track me across the net when I'm logged in so I never log into them except in a private window. This works great when my browser has the name/password saved because I go to the site and its one click to login. It sucks though when it's email login. I now have to click "login", wait 10 second to 3 minutes for the email to arrive. Copy the link from the email to the private window. It basically means I avoid using that site most of the time. (Medium)
- NoodleIncident 6y ago
  Would something like Firefox's containers(?) help you for these sites? There's a way to leave a single tab signed in without having it leak the fact that you're logged in to your other browser tabs, rather than logging in each time you use the site in a new private session. It's even possible to log in to the same site on multiple accounts with this feature.
- movedx 6y ago
  You're not my target audience and you have an esoteric approach to privacy.
  - codemac 6y ago
    Most of my friends/family who use work laptops/computer do the same thing - they log in via a private browser so they don't get work credentials mixed with personal credentials. I think firefox containers are a great way to handle this, and a lot of folks don't know how to use chrome or other browsers with multiple identities. Maybe look past that this user is doing it for privacy.
    - movedx 6y ago
      I believe the inconveniences are worth it when your users aren't power users or even that proficient with a computer; and your users select passwords like "snoopy55" or "ilovejesus". If the aim of the game is to produce a non-critical system that's accessed rarely, and your users need protecting against themselves, then this "magic token" approach works fine. I can't please everyone, and those who I can't please I'm happy to lose as (paying) users/customers.
OJFord 6y ago
FWIW, I hate this about the couple of apps I use that do this (with no other option, e.g. Notion added a password option). And not for privacy concerns, as a sibling thread is discussing, but simply because I find it considerably less convenient than a password, as most things use, and as I'm set up to conveniently use and expect. It's especially annoying when setting up a new device - oh right yes, obviously I need to set up my email app before this one... And what if I don't have or want or can't currently for whatever reason receive email on that device? Now I'm trying to get it there by some other means, only to find it times out in the process. (This is all happened to me, and enough that I'm ranting about it...)
- cstejerean 6y ago
  For anything I use with any kind of regularity I’d hate it. I already have this problem with services that decide they really need to send me some code by email because they don’t recognize my device (because it’s been more than 30 days and Safari killed their cookies). And then every once in a while the email doesn’t show up for 45 minutes for some reason, leaving me with no recourse. But for certain things that I need to do say once a year (let’s say renew some kind of registration or insurance) I wouldn’t mind it. Because chances are I already do this because I forgot to save the password in my password manager last time and now I need to do a reset password flow anyway.
  - movedx 6y ago
    > For anything I use with any kind of regularity I’d hate it. I already have this problem with services that decide they really need to send me some code by email because they don’t recognize my device (because it’s been more than 30 days and Safari killed their cookies). And then every once in a while the email doesn’t show up for 45 minutes for some reason, leaving me with no recourse. It's incredible to me how impatient we've become as a society. As everything is given to us faster and faster, with less and less financial cost, the more we demand this of everything going forward. Anything that comes shy of this demand by mere minutes is shunned as unacceptable.
    - 6y ago
skinnymuch 6y ago
I am not too privacy oriented like another post. I just don’t like having to go to my email to log in. It’s a hassle vs my saved password being auto filled or using an Oauth login. But Most other people seem to shrug it off and do it. So seems like it’ll keep becoming more common.
mekster 6y ago
This is just being lazy over customer experience. I don't like having have to click the link, trash the email and close the previous login tab. > I can use manual processes to verify the person What does this mean?
- movedx 6y ago
  > This is just being lazy over customer experience. Can you expand on this? My users actually voted for this feature.
  - mekster 6y ago
    I explained it right below. I see some might like it that way for security reasons.
protoduction 6y ago
I'm toying with the idea of building this as a service (I made a landing page last week [0]), but I'm not sure enough would pay for the convenience of having this as a service. The service would handle token generation, verification, and e-mail sending through an API. [0]: https://magiclogin.net https://magiclogin.net
- teleforce 6y ago
  This my friend is utterly brilliant!
- scrollaway 6y ago
  isn't that the same as https://magic.link https://magic.link?
  - protoduction 6y ago
    The base idea is the same yes, but the pricing and featureset are different. Magic.link is venture funded with steep pricing per user. This makes sense for their enterprise target market, but for a hobby project I can't remotely afford it. They keep a record for you of your users, in my product that's your own responsibility (which imo is a good thing). tldr: What I'm building is simpler, and much more affordable, but not enterprise-feature complete.
    - merlinsbrain 6y ago
      What would your pricing be? Starter pack at $35/month for 500 users sounds like $35/month and I outsource auth to a company that is also on the hook for “enterprise” security :) I think it’s awesome you’re building an alternative with a different feature set, I’m really curious to hear your take on pricing.
      - protoduction 6y ago
        The pricing is listed on the website, but it's about 10-20% of that. You would pay around 0.50 per 1000 emails. Depending on how often your users sign in and how long you keep them logged in for the the percentage may be lower or higher. Not offering SAML/SSO/OIDC etc simplifies the problem a lot allowing me to offer it cheaply. The largest cost is sending the e-mails reliably, for which I am wrapping Amazon SES.
miguelmota 6y ago
Username + password is nice when you have a password manager that auto-inserts the credentials for you into the form. The 1Password extension and browsers with builtin password managers do this. All I have to do is click login and I’m in. The magic link flow is more of an inconvenience in this regard because it involves jumping around apps.
artificialLimbs 6y ago
As an alternative...I wonder if there could be a auth process where the user creates a writeable 'space' for a site/app with a one time key in their password manager, gives the site/app the key, then the site uploads new login credentials directly into the password manager.
- ed25519FUUU 6y ago
  You mean like FIDO?
  - artificialLimbs 6y ago
    Eh, yes. Thank you. =)
cortesoft 6y ago
So there is no way to login on any device that isn’t your own?
- movedx 6y ago
  You can login to any device on which you can login to your email. Most people can login to their from anywhere, on any device, via a browser. I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important.
  - greggman3 6y ago
    > I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important So basically this is not a solution for 99% of all services. Thanks for clarifying
    - movedx 6y ago
      You're right, Slack isn't really that popular and totally doesn't use magic tokens /s
- protoduction 6y ago
  You can extend this idea to include a one time code in the email that can be manually typed on another device. Including a QR code of the link also helps.
mooreds 6y ago
Another bonus with magic links. In my experience people pay waaaay more attention to their email accounts than they do to almost any other authentication system they interact with. So chances are higher that they'll have a secure password, rotate their password, maybe even have MFA. (I said higher, but I didn't say likely ;) .) Anyway, I think for certain kinds of applications this is a fantastic auth solution. The only possible downside is that you've introduced a dependency on mail deliverability into a core piece of your application. But email deliverability may be a big enough issue that you want it solved anyway.
jamil7 6y ago
I did the exact same for a recent project, a small internal tool for geo data collection in cities. It comes with tradeoffs as others have mentioned but it’s pretty great for getting something going quickly with a small number of users. All you need is mailgun or similar key and you’re off.
conductr 6y ago
I don't mind this. 7/10 times I'm doing the password reset thing already when I visit a site I don't use much but know I have an account with, so this just cuts to the chase I'm already logged into Chrome browser, thus gmail, so it would be great if I didn't have to manually go over to gmail and click your link
pchm 6y ago
Implemented this recently in my SaaS app, replacing passwords with magic links and it was a mistake. Sure, it has some obvious benefits: it forces users to always provide a valid email and logging in confirms that the email address is valid, without any additional logic. But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are quite common now. People use email they didn't sign up with, messages go to spam, arrive with a delay - or recently, gmail outage caused messages to hard-bounce. These are only some of the issues I've had to deal with in the last few weeks, that never came up when I had password auth. Also, I've found that some email clients automatically follow links included in the message and that meant login link was invalidated before user got a chance to click it. I've solved it by adding a button on the page, but it's not ideal. Magic links were supposed to be convenient, but they cause a lot of frustrations for some users. Keep that in mind.
- pelasaco 6y ago
  I was bitten by this issue already two times. First time wth magic links via email. Suddenly your application depends on the mail infrastructure that sometimes is hard to "scale on demand" or even isn't under your control. Second time with OTP via SMS. Both incidents led us to be unreachable for long periods of time, and the SLA provided by our mail provider and telecom weren't really known until the incident. We assumed that everything would just work under high load.
  - iKevinShah 6y ago
    Quality insight from someone who has actually gone through this. Thank you! If you could share, can you share what exactly led to the discovery that things are unreachable. Were there any status check mechanisms you were able to put in place to check that incident was raised and / or solved? Also, do you still continue that (Email login / OTP login) OR is it moved something else?
    - pelasaco 6y ago
      > If you could share, can you share what exactly led to the discovery that things are unreachable. We have some heavy monitoring with InfluxDB and Grafana built in our application and one of the alerts is if the number of logins/minute drop under a threshold. That's how we noticed it first time. The main reason was some network issues affecting our mail server provider. We were holding on a support ticket with our provider while trying to find a solution to our customers. After that we added as well we extended this monitoring to the mail queue. To be fair we used to monitor it before, but with the infra team, now we have it in our SRE dashboard, with Slack notifications and etc. > Also, do you still continue that (Email login / OTP login) OR is it moved something else? The OTP as second factor of authentication is something that we couldn't disable, but it's a requirement for one very specific application. We just looked for different partners with better SLA and built some monitoring around it. The Email login is still there, but we didn't roll-out it to all our applications as we initially intended to. We are still studying what would be the best solution here. The company is heavy user of microsoft's 365 mail service, and although the overall experience is pretty good, we have 0 influence in their SLA if we get impacted by any issue on their side. I don't think that the solution is bad per-se, just you have to plan mail infrastructure as core part of your application.
nojs 6y ago
This is so annoying as a user! It’s like you’re making me do a password reset every time I want to log in, and I have to sit there and wait until the email arrives.
pelasaco 6y ago
> password handling workflows are now the email provider's problem. if the web app isn't critical, I think that's a great solution. If the application is critical, then you have to pull in the e-mail system as critical component from your application (as critical as the database, application server and etc)

by movedx 6y ago

eloff 6y ago

I had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email. Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where requests would be routed through different exit IP addresses in different regions for the same user. On top of that, 5 seconds later it would repeat a request. Not just GET requests either, but also POST requests. How they get by without horrible things happening is beyond me. This completely broke user sessions since any login attempt would be followed by a second login for the same user which invalidated the session token. Imagine trying to use your online bank with that network. If anyone has seen anything similar in the wild, I'd love to hear from you. We never figured out what software they have that does that. We changed how our sessions work to get around it, but it probably ranks as the most bizarre issue I've encountered in my 20 year career.

pwdisswordfish4 6y ago
> We changed how our sessions work to get around it In other words, you fixed the bugs in how your original implementation relied on bad assumptions that it shouldn't have tried to rely on to begin with. The only real quibble here might be that duplicate requests cost you unnecessary transit.
- eloff 6y ago
  Duplicate POST requests are a violation of the HTTP standard because they are not assumed to be idempotent. I hope you're just misunderstanding the problem.
schoolornot 6y ago
Not that uncommon for large companies to bring their IP space in house to multihome and load-balance traffic across multiple providers. If they are routing traffic back to random data centers for centralized filtering, it makes sense how it could be coming from different regions. I'm more interested in what made your application sensitive to this. The duplicate packets does sound bizarre. Maybe a mirroring issue or firmware issue.
- eloff 6y ago
  The changing ips were ok, it just made diagnosing the issue difficult in the logs. The duplicate requests (not at the packet level as TCP ignores duplicate packets) were the root cause of the issue.
  - mst 6y ago
    Reminds me of the "fun" of dealing with a RADIUS system that would, about 20% of the time, send me two START packets for the same session ... with different sequence numbers. This made successfully managing dynamic IP pool allocation on my end an ... interesting ... experience ;)

madjam002 6y ago

I have tried something similar, although I am encountering issues with people having to wait 10+ minutes for their codes at times, yet sometimes it arrives immediately, which is frustrating when it comes to login. I haven't spent any time debugging in depth yet, apart from looking at the email headers and seeing that it takes over 5 mins for the email to get from SES to Gmail. Not sure why!

542458 6y ago
MXroute has a blogpost where he digs into this a bit. IIRC it actually gets accepted by Google immediately - but then spends 5mins in the ether inside Google before it hits a Gmail inbox. No way to tell what the delay is coming from, other than it appears to be out of our hands. Edit: https://mxroute.com/delayed-delivery-to-gmail/ https://mxroute.com/delayed-delivery-to-gmail/

sebmellen 6y ago

There's a great project called Portier [0], which does this quite nicely. I highly recommend it. It's a successor of sorts to the ill-fated Mozilla Persona project [1]. > Portier (pronounced "Por-tee-ay") is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password. [0]: https://portier.github.io/ https://portier.github.io/ [1]: https://en.wikipedia.org/wiki/Mozilla_Persona https://en.wikipedia.org/wiki/Mozilla_Persona

nickthemagicman 6y ago

This is a really cool idea. So they basically go to their email and verify and it stores a token in their cookies?

movedx 6y ago
Exactly. They login by just providing their email. It sens a link with a unique code in it. This code is checked against the DB and if it's correct, they get a cookie (the digital kind ;])
- eps 6y ago
  Beware of setups that verify (i.e. visit) all links in an email upon receiving one. This completely breaks one-time use login links.

gfxgirl 6y ago

I know I'm the exception but as a privacy oriented user I hate this. There are services that try to track me across the net when I'm logged in so I never log into them except in a private window. This works great when my browser has the name/password saved because I go to the site and its one click to login. It sucks though when it's email login. I now have to click "login", wait 10 second to 3 minutes for the email to arrive. Copy the link from the email to the private window. It basically means I avoid using that site most of the time. (Medium)

NoodleIncident 6y ago
Would something like Firefox's containers(?) help you for these sites? There's a way to leave a single tab signed in without having it leak the fact that you're logged in to your other browser tabs, rather than logging in each time you use the site in a new private session. It's even possible to log in to the same site on multiple accounts with this feature.
movedx 6y ago
You're not my target audience and you have an esoteric approach to privacy.
- codemac 6y ago
  Most of my friends/family who use work laptops/computer do the same thing - they log in via a private browser so they don't get work credentials mixed with personal credentials. I think firefox containers are a great way to handle this, and a lot of folks don't know how to use chrome or other browsers with multiple identities. Maybe look past that this user is doing it for privacy.
  - movedx 6y ago
    I believe the inconveniences are worth it when your users aren't power users or even that proficient with a computer; and your users select passwords like "snoopy55" or "ilovejesus". If the aim of the game is to produce a non-critical system that's accessed rarely, and your users need protecting against themselves, then this "magic token" approach works fine. I can't please everyone, and those who I can't please I'm happy to lose as (paying) users/customers.

OJFord 6y ago

FWIW, I hate this about the couple of apps I use that do this (with no other option, e.g. Notion added a password option). And not for privacy concerns, as a sibling thread is discussing, but simply because I find it considerably less convenient than a password, as most things use, and as I'm set up to conveniently use and expect. It's especially annoying when setting up a new device - oh right yes, obviously I need to set up my email app before this one... And what if I don't have or want or can't currently for whatever reason receive email on that device? Now I'm trying to get it there by some other means, only to find it times out in the process. (This is all happened to me, and enough that I'm ranting about it...)

cstejerean 6y ago
For anything I use with any kind of regularity I’d hate it. I already have this problem with services that decide they really need to send me some code by email because they don’t recognize my device (because it’s been more than 30 days and Safari killed their cookies). And then every once in a while the email doesn’t show up for 45 minutes for some reason, leaving me with no recourse. But for certain things that I need to do say once a year (let’s say renew some kind of registration or insurance) I wouldn’t mind it. Because chances are I already do this because I forgot to save the password in my password manager last time and now I need to do a reset password flow anyway.
- movedx 6y ago
  > For anything I use with any kind of regularity I’d hate it. I already have this problem with services that decide they really need to send me some code by email because they don’t recognize my device (because it’s been more than 30 days and Safari killed their cookies). And then every once in a while the email doesn’t show up for 45 minutes for some reason, leaving me with no recourse. It's incredible to me how impatient we've become as a society. As everything is given to us faster and faster, with less and less financial cost, the more we demand this of everything going forward. Anything that comes shy of this demand by mere minutes is shunned as unacceptable.
  - 6y ago

skinnymuch 6y ago

I am not too privacy oriented like another post. I just don’t like having to go to my email to log in. It’s a hassle vs my saved password being auto filled or using an Oauth login. But Most other people seem to shrug it off and do it. So seems like it’ll keep becoming more common.

mekster 6y ago

This is just being lazy over customer experience. I don't like having have to click the link, trash the email and close the previous login tab. > I can use manual processes to verify the person What does this mean?

movedx 6y ago
> This is just being lazy over customer experience. Can you expand on this? My users actually voted for this feature.
- mekster 6y ago
  I explained it right below. I see some might like it that way for security reasons.

protoduction 6y ago

I'm toying with the idea of building this as a service (I made a landing page last week [0]), but I'm not sure enough would pay for the convenience of having this as a service. The service would handle token generation, verification, and e-mail sending through an API. [0]: https://magiclogin.net https://magiclogin.net

teleforce 6y ago
This my friend is utterly brilliant!
scrollaway 6y ago
isn't that the same as https://magic.link https://magic.link?
- protoduction 6y ago
  The base idea is the same yes, but the pricing and featureset are different. Magic.link is venture funded with steep pricing per user. This makes sense for their enterprise target market, but for a hobby project I can't remotely afford it. They keep a record for you of your users, in my product that's your own responsibility (which imo is a good thing). tldr: What I'm building is simpler, and much more affordable, but not enterprise-feature complete.
  - merlinsbrain 6y ago
    What would your pricing be? Starter pack at $35/month for 500 users sounds like $35/month and I outsource auth to a company that is also on the hook for “enterprise” security :) I think it’s awesome you’re building an alternative with a different feature set, I’m really curious to hear your take on pricing.
    - protoduction 6y ago
      The pricing is listed on the website, but it's about 10-20% of that. You would pay around 0.50 per 1000 emails. Depending on how often your users sign in and how long you keep them logged in for the the percentage may be lower or higher. Not offering SAML/SSO/OIDC etc simplifies the problem a lot allowing me to offer it cheaply. The largest cost is sending the e-mails reliably, for which I am wrapping Amazon SES.

miguelmota 6y ago

Username + password is nice when you have a password manager that auto-inserts the credentials for you into the form. The 1Password extension and browsers with builtin password managers do this. All I have to do is click login and I’m in. The magic link flow is more of an inconvenience in this regard because it involves jumping around apps.

artificialLimbs 6y ago

As an alternative...I wonder if there could be a auth process where the user creates a writeable 'space' for a site/app with a one time key in their password manager, gives the site/app the key, then the site uploads new login credentials directly into the password manager.

ed25519FUUU 6y ago
You mean like FIDO?
- artificialLimbs 6y ago
  Eh, yes. Thank you. =)

cortesoft 6y ago

So there is no way to login on any device that isn’t your own?

movedx 6y ago
You can login to any device on which you can login to your email. Most people can login to their from anywhere, on any device, via a browser. I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important.
- greggman3 6y ago
  > I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important So basically this is not a solution for 99% of all services. Thanks for clarifying
  - movedx 6y ago
    You're right, Slack isn't really that popular and totally doesn't use magic tokens /s
protoduction 6y ago
You can extend this idea to include a one time code in the email that can be manually typed on another device. Including a QR code of the link also helps.

mooreds 6y ago

Another bonus with magic links. In my experience people pay waaaay more attention to their email accounts than they do to almost any other authentication system they interact with. So chances are higher that they'll have a secure password, rotate their password, maybe even have MFA. (I said higher, but I didn't say likely ;) .) Anyway, I think for certain kinds of applications this is a fantastic auth solution. The only possible downside is that you've introduced a dependency on mail deliverability into a core piece of your application. But email deliverability may be a big enough issue that you want it solved anyway.

jamil7 6y ago

I did the exact same for a recent project, a small internal tool for geo data collection in cities. It comes with tradeoffs as others have mentioned but it’s pretty great for getting something going quickly with a small number of users. All you need is mailgun or similar key and you’re off.

conductr 6y ago

I don't mind this. 7/10 times I'm doing the password reset thing already when I visit a site I don't use much but know I have an account with, so this just cuts to the chase I'm already logged into Chrome browser, thus gmail, so it would be great if I didn't have to manually go over to gmail and click your link

pchm 6y ago

Implemented this recently in my SaaS app, replacing passwords with magic links and it was a mistake. Sure, it has some obvious benefits: it forces users to always provide a valid email and logging in confirms that the email address is valid, without any additional logic. But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are quite common now. People use email they didn't sign up with, messages go to spam, arrive with a delay - or recently, gmail outage caused messages to hard-bounce. These are only some of the issues I've had to deal with in the last few weeks, that never came up when I had password auth. Also, I've found that some email clients automatically follow links included in the message and that meant login link was invalidated before user got a chance to click it. I've solved it by adding a button on the page, but it's not ideal. Magic links were supposed to be convenient, but they cause a lot of frustrations for some users. Keep that in mind.

pelasaco 6y ago
I was bitten by this issue already two times. First time wth magic links via email. Suddenly your application depends on the mail infrastructure that sometimes is hard to "scale on demand" or even isn't under your control. Second time with OTP via SMS. Both incidents led us to be unreachable for long periods of time, and the SLA provided by our mail provider and telecom weren't really known until the incident. We assumed that everything would just work under high load.
- iKevinShah 6y ago
  Quality insight from someone who has actually gone through this. Thank you! If you could share, can you share what exactly led to the discovery that things are unreachable. Were there any status check mechanisms you were able to put in place to check that incident was raised and / or solved? Also, do you still continue that (Email login / OTP login) OR is it moved something else?
  - pelasaco 6y ago
    > If you could share, can you share what exactly led to the discovery that things are unreachable. We have some heavy monitoring with InfluxDB and Grafana built in our application and one of the alerts is if the number of logins/minute drop under a threshold. That's how we noticed it first time. The main reason was some network issues affecting our mail server provider. We were holding on a support ticket with our provider while trying to find a solution to our customers. After that we added as well we extended this monitoring to the mail queue. To be fair we used to monitor it before, but with the infra team, now we have it in our SRE dashboard, with Slack notifications and etc. > Also, do you still continue that (Email login / OTP login) OR is it moved something else? The OTP as second factor of authentication is something that we couldn't disable, but it's a requirement for one very specific application. We just looked for different partners with better SLA and built some monitoring around it. The Email login is still there, but we didn't roll-out it to all our applications as we initially intended to. We are still studying what would be the best solution here. The company is heavy user of microsoft's 365 mail service, and although the overall experience is pretty good, we have 0 influence in their SLA if we get impacted by any issue on their side. I don't think that the solution is bad per-se, just you have to plan mail infrastructure as core part of your application.

nojs 6y ago

This is so annoying as a user! It’s like you’re making me do a password reset every time I want to log in, and I have to sit there and wait until the email arrives.

pelasaco 6y ago

> password handling workflows are now the email provider's problem. if the web app isn't critical, I think that's a great solution. If the application is critical, then you have to pull in the e-mail system as critical component from your application (as critical as the database, application server and etc)