The killer feature is that it's embeddable into your app. You don't have to host anything besides your app and your app's database.
I can't understand why people who aren't Google scale do it any other way. When you're at the point where you need a separate auth service I'd call that good problems to have.
> The killer feature is that it's embeddable into your app. You don't have to host anything besides your app and your app's database.
That's why they're gonna monetize by building a cloud service?
Does it also embed two-factor authentication, confirmation/reset emails for me? Those are the reasons one might want to go with Firebase.
Here's an article[0] (on my employer's website) that talks through some of the things to think about when choosing an authentication solution. (It's a bit old so doesn't discuss BetterAuth directly.)
An embeddable library is great for one application; simplifies development and deployment. You can have foreign keys directly to user ids. It's the reason Devise or Spring Security are great for single applications
Yet breaking out authentication to a separate service is one of the first things broken out a certain scale. Why?
You might say "I'll only have one application for the foreseeable future", but you might think about about any SaaS applications you'd want to have your customers use (support ticketing, training, public forums/communities). And mobile applications. And applications for different segments of your userbase.(The multiple app case is much stronger for IAM/Workforce, part of why Okta is a 17B company.)
Such a migration can be complex, so if you can see needing any of the above things soon, it can make sense to start with a sep auth server. You don't need to be google scale to get the benefits.
0: https://fusionauth.io/articles/identity-basics/complete-auth...