Adding "sign in with google" and "sign in with apple" (especially google with FedCM) gives you auth with the least amount of friction you can get, since they end up being one-click events for most users.
Having said that, none of this prevents people from creating fake accounts. On our system I can see people regularly signin in with multiple google accounts, with incrementing digits in the name, trying to abuse the free tier. You'll need to build something yourself for that, depending on your risk surface. For us this involves tracking requests across IP addresses, blocking free access from data centre IPs, blocking bots using AWS WAF, analyzing task patterns to spot people who use multiple residential IPs and a bit more.
I really wanted to avoid Oauth providers and keep the auth in-house only. For a more serious site like an e-commerce or a SaaS sure, but for a very low stakes site I wanted to see what's possible with minimal 3rd party dependencies.
I'm sure many users prefer the Google/Github/Apple/Twitter? buttons, and the moment they see a email+password only wall they bounce, but I think that offering a username + auto suggested password is a superb UX.
I wanted to hear if someone who went this route later regretted it, or if they are happy with it and how they solved the problems that may appear. Mainly abuse and forgot password flows (just count that user as forever gone?).
Sorry I should have put in the post that I don't want to use Oauth because I want to see what's possible with a non 3rd party auth. I always see the "dont roll your own auth" message being tossed around, and this site provides a great lab for testing the waters of owning auth: no email to leak, nothing serious to protect.
Adding "sign in with google" and "sign in with apple" (especially google with FedCM) gives you auth with the least amount of friction you can get, since they end up being one-click events for most users.
Having said that, none of this prevents people from creating fake accounts. On our system I can see people regularly signin in with multiple google accounts, with incrementing digits in the name, trying to abuse the free tier. You'll need to build something yourself for that, depending on your risk surface. For us this involves tracking requests across IP addresses, blocking free access from data centre IPs, blocking bots using AWS WAF, analyzing task patterns to spot people who use multiple residential IPs and a bit more.
I really wanted to avoid Oauth providers and keep the auth in-house only. For a more serious site like an e-commerce or a SaaS sure, but for a very low stakes site I wanted to see what's possible with minimal 3rd party dependencies.
I'm sure many users prefer the Google/Github/Apple/Twitter? buttons, and the moment they see a email+password only wall they bounce, but I think that offering a username + auto suggested password is a superb UX.
I wanted to hear if someone who went this route later regretted it, or if they are happy with it and how they solved the problems that may appear. Mainly abuse and forgot password flows (just count that user as forever gone?).
I made a project for this use case exactly at cloudprototype.org that lets you setup auth on one of these low stakes projects.
use oauth buttons, it's a single click for users with apple/google (i.e.)
there are several auth SaaS providers you could look to for inspiration or adoption
tl;dr - clicking a few buttons at prompts is much less effort (and more commonplace) than unam+pword
Sorry I should have put in the post that I don't want to use Oauth because I want to see what's possible with a non 3rd party auth. I always see the "dont roll your own auth" message being tossed around, and this site provides a great lab for testing the waters of owning auth: no email to leak, nothing serious to protect.