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.
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...)
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.
> 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.
I don't get this comment. I've been in plenty of situations where I need something now. Doctors office, DMV, tax office, etc...
It's not about being impatient. It's about knowing that it should be instant and it not being instant. If you turned on your water faucet, shower, or flushed your toilet and water didn't run for 45 minutes most people would be shocked.
I'm not saying I'm better than anyone else, I'm simply pointing out that having now slowed down and become more patient, I don't complain when accessing information from the other side of the planet takes 3 minutes instead of 3 seconds.
That is what this essentially boils down to: convenience and patience. We're losing the latter because of the former.
You may want to work on your phrasing then, because that was sure the way it came off. You say that culturally we’re a certain way and then that you feel that you’re a better person for being different.
E-mail, especially when the MTA and MUA is connected to different environments, which requires relaying, could be particular slow (minutes, hours) if the e-mail hops on busy services.
And as I discovered in my own service: If the SMS aren't being sent - or the clients aren't getting them - there are so many parts involved that's really hard to pinpoint the problem and get an ETA for the solution..
Yeah, I am not a fan of magic tokens / login by email address either. It's a pain to need to message yourself with a token url and then the messenger app does previews which renders the token invalid and then you need to save a text file with the url in it, send it open it, copy paste the url into the browser. Just to login.
Sure, you could say, why don't setup your email on your devices but I shouldn't need to do that. Just to use your website. These magic links are just not user friendly
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.
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.
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?
> 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.
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)
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.
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.
Those people are also far more likely to have their email breached, along with the logins you provided on a silver platter. Also they can't log in to your site when the third party email provider goes down. I understand why you prefer this approach for your site, but can not recommend having such strong third party dependencies.
Also, personally, not a fan of losing access because e.g: Google disabled my account. I avoid google and fb login like the plague. (I am slowly looking to migrate off/away)
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.
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.
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.
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.
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 ;)
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
I’m not very vested in a solution at the moment, but if I had a set of users < 500, the flat pricing of Magic Link kind of makes more sense to me, I don’t want to be worrying about how many times they sign in.
That being said, I can imagine there are people who would prefer a per sign in model, it’s just a level of granularity I don’t care for.
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!
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.
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.
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.
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.
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
> 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)
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.
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 ;])
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"