3 ms·

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

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.

apitman 3y ago
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.
- v2223943777435 3y ago
  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.
  - apitman 3y ago
    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.

apitman 3y ago

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.

v2223943777435 3y ago
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.
- apitman 3y ago
  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.