3 ms·

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 peop

by Spivak 1y ago

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.

koakuma-chan 1y ago
> 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?
- Spivak 1y ago
  I mean right now it's JS's devise. There's always time in the future for them to ruin it.
uh_uh 1y ago
Does it also embed two-factor authentication, confirmation/reset emails for me? Those are the reasons one might want to go with Firebase.
- trollbridge 1y ago
  Another reason to use Firebase is because they can provide a lot the advanced security (e.g. blacklists for 2FA phone numbers/emails coming from an algorthm whose innards are only known to Google).
- notpushkin 1y ago
  It does 2FA. You have to implement emails yourself, but honestly it’s not that big of a deal (you likely have to do other emails for your app anyway). It also does a bunch of other auth things, like OIDC.
mooreds 1y ago
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? * single sign-on between applications (if you have more than one) * eliminate a user data silo (if you have more than one application) * different security/legal requirements between PII/credentials of users and application data * a desire to hang multiple applications off of one identity store for data consistency * separate deployment cadences 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-authentication-system https://fusionauth.io/articles/identity-basics/complete-auth...

by Spivak 1y ago

koakuma-chan 1y ago

> 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?

Spivak 1y ago
I mean right now it's JS's devise. There's always time in the future for them to ruin it.

uh_uh 1y ago

Does it also embed two-factor authentication, confirmation/reset emails for me? Those are the reasons one might want to go with Firebase.

trollbridge 1y ago
Another reason to use Firebase is because they can provide a lot the advanced security (e.g. blacklists for 2FA phone numbers/emails coming from an algorthm whose innards are only known to Google).
notpushkin 1y ago
It does 2FA. You have to implement emails yourself, but honestly it’s not that big of a deal (you likely have to do other emails for your app anyway). It also does a bunch of other auth things, like OIDC.

mooreds 1y ago

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? * single sign-on between applications (if you have more than one) * eliminate a user data silo (if you have more than one application) * different security/legal requirements between PII/credentials of users and application data * a desire to hang multiple applications off of one identity store for data consistency * separate deployment cadences 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-authentication-system https://fusionauth.io/articles/identity-basics/complete-auth...