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"
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...)
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.
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.
A friendly nudge: google 'spiritual ego trap' and then read this comment again.
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.
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.
> Contacting Toilet Cloud Server...
> 503 Service Unavailable
> Alert User: "Water Unavailable, Please try Later."
There's something very appealing about not having a password that I need to store anywhere for that service too.
MFA usually uses channels that are intended to be relative low latency (or that don't require realtime out-of-band transmission, like TOTP).
Email, OTOH, isn't generally reliably low-latency
Email or text would work the same for this auth scheme anyway.
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
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.
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?
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 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.
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.
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)
I'm sure you can have a browser extension to block cookies and other tracking information on these sites.
I use Brave with maximum security and privacy settings with a VPN in addition to using Tor and haven't had any issues.
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.
This made successfully managing dynamic IP pool allocation on my end an ... interesting ... experience ;)
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.
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.
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.
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.
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.
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.
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.
Good luck!
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?
Can you expand on this? My users actually voted for this feature.
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!
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
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'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
Including a QR code of the link also helps.
So they basically go to their email and verify and it stores a token in their cookies?
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 ;])