Ask HN: How to implement a friction-less auth | Hacker News Reader

Ask HN: How to implement a friction-less auth

1 pointwastedpotencial5 comments

I'm kinda new to coding and developing a very simple two-player board game and need guidance in how to design the auth system. Right now I have a normal username+password auth wall for a registered users only queue and a guest system for non registered users that mints a guest account when someone not logged in queues. I'm happy with the friction-less this provides but I'm not so happy with anyone being able to spam either my guest creation endpoint or my username+pwd signup.

I love sites that offer either functional guests or fast non-email signups, but I don't know how to prevent someone from creating fake accounts and making the matchmaking awful besides rate limiting, but as the expected pool of legitimate players is small, any trivial amount of fake accounts (10s) can severely impact the queues.

I know, I know, "0 users" and "just put something out there", but I really enjoy the back-and-forth of the design and implementation, just a bit lost here so any guidance on what to do, but scoped to the small stakes of the project, would be much appreciated.

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.

Reply on news.ycombinator.com