When building Hyikko, one of the first decisions I had to make was choosing an authentication system. After evaluating several options, OAuth (Google OAuth) emerged as the clear winner. Here's why.
Traditional authentication systems require users to create new accounts, remember passwords, and go through email verification processes. This creates friction that can significantly reduce user adoption rates.
What else, it requires me, the developer - to verify the user, manage his token, handle password resets, encrypt passwords, etc. Yach.
The solution? Let one of the big players handle all of that for you, while you can focus on your app.
And here comes OAuth - a protocol that allows you to do just that.
Users can sign in with one click using their existing account.
No password creation, no email verification, no forgotten password issues.
The provider handles user verification, 2FA, and account recovery.
You don't have to worry about storing passwords, or implementing complex security measures.
Someone else's trusted servers verify your user & manages his token for you.
Providers give you verified email addresses, profile pictures, and basic user information, but often you can get more useful specific data for your app - you couldn't get otherwise.
i.e. GitHub can provide commit data on your user (if you chose the right scope).
I spent about 2 hours setting up Google OAuth with NextAuth.js.
To start with - it's free to use, free to maintain and free to scale. Once crossing a certain user amount, you'll probably have to pay for the service, but that's a small price to pay for the convenience. You would have ended up paying more doing all of that yourself, not even considering the development time!
Also - NexuAuth can be provider agnostic, meaning you can implement multiple providers in your app, rather easily.
While NextAuth can make it tempting to implement multiple providers right of the get-go, I suggest starting with one.
More providers still means more time to implement, and you might find that you need to change direction with different providers or that OAuth might not be the best choice for you - and that's fine.
If you're app user-base is a wide range of people like mine (teens, adults, tech-savvy's, non-tech-savvy's, different OS's, etc.), Google OAuth is probably the choice fo you.
According to many surveys, Google still dominates when it comes to user-base and account coverage (here's descope's 2025 breakdown source).
Software engineers? GitHub OAuth might work better.
Teens? Using one of the social providers (i.e. Facebook or Twitter) might work better.
IOS App? Apple OAuth might work better.
Here's an example - Google's id_token (access token) is valid for 1 hour, and needs to be refreshed afterwards. Other providers might have different configurations.
Your app's use-case might want less or more then that - but there's abosultly nothing you can do about it.
Yep, some people dont use Google, Facebook or Apple. Especially users of certain demographics (i.e. older adults).
This brings us back to username & password which sucks, but this case is pretty rare, and if you support multiple providers - in most cases, that should cover all your users.