If you believe email to be the weakest link in the chain, then you have to get rid of email password resets too and use reset codes instead. Lose your codes, lose your account.
With these servers/services you can usually chain to another identity source (e.g. ldap directory+kerberos) so that would fall to the origin identity service. But even if you don't chain it the owner of OIDC provider will usually provide an administrator role and integration system accounts that can be used as an out of band sort of user account recovery mechanism.
There is one difference here - email reset would lock the legitimate user out of the account, whereas email magic links would not. I think that's an advantage for the former.
On the surface yes. In practice, it's more like email + whatever kind of security system your email provider has set up to verify its really you.
I.e. try to log into a gmail account from a new machine in an unfamiliar location, even if you know the password and can receive SMS codes.
So right now, I'm more worried about getting locked out of a mail account than that someone else could take it over.
As for unencrypted SMPT, there is SMTPS [1]. I'm not sure if this seever supports it, but I'd assume it would be a basic requirement if you want to communicate with real-world mailboxes and not instantly flagged as spam.
just because email is often the defacto identity on the internet doesn't make it a good idea (bandwagon fallacy). i don't consider email tokens to be a serious form of authentication. unless you send the user their authentication secret with data encrypted by the user's public key, i strongly recommend against any use of email-based authentication.
* there are a huge number of middlemen in emailing that you have to trust. the sending email provider, the receiving email provider, ISP, email client, the device the client resides on. and everyone else in between.
* unless you're just hosting an email server on your local network, starting up an email server that can successfully get its messages across the internet to your intended recipient is an extremely high barrier.
email is an extremely error-prone protocol. there's lots of reasons that government/health organizations don't send you personal private information by email and instead send you an email that says to come log into their secure platform to view the private information.
There are mitigations for these security issues. The most important is that you only email the user a random code which is bound to the browser login attempt session. The user is required to enter the code they received in that session. This removes the need to trust any of the parties you listed.
you still have to trust the client device. but i guess if someone else is there you're screwed anyway.
also, email has a potential for a big delay. a lot of times people need to log in quickly. email doesn't always reach the destination in a timely manner.
The UX challenges are real, no doubt about that. That's actually one of the main reasons I started down the OIDC rabbit hole. I was using only passwordless email logins on my services, and wanted to provide my users with the UX of social login without forcing them to give up their privacy to ad companies.
Huh, I honestly didn't know it was that big. Forgive my ignorance, I've never really used Whatsapp. Can you send a message to someone that hasn't added you as a contact? If so I would seriously consider implementing this as an alternative to email.
The main problem is that it's not federated and completely under Facebook's control. Also, identity based on WhatsApp is still vulnerable to simjacking, correct?
> The main problem is that it's not federated and completely under Facebook's control. Also, identity based on WhatsApp is still vulnerable to simjacking, correct?
