

Ask HN: Why do so many startups simply depend on FB alone, for the login? - vijayr

I mean, I understand that FB has half a billion users etc etc.  So it makes sense to use FB's auth, but doesn't it make sense to also give the option to register with them separately?  For example, I wanted to try cardflick, but I can't, as the only way to get in, is using FB, and I don't have a FB account anymore :(<p>It'll hardly take a couple of hours to write a simple login script, no?
======
ig1
Because developer time is incredibly valuable to startups, the amount of users
who don't want to use facebook/google/etc is relatively small so it's not
worth spending the extra time to implement.

I think you underestimate the complexity of managing your own auth. It takes a
lot longer than a couple of hours to do it right. Testing alone would take
longer than that. Authentication is one of the most important part of many
apps, it's not something you should be skimping on or doing in a hurry. It's
much better to pass it off to a third-party until you have the time and
resources to do it correctly.

(here's a bunch of things you might not have considered: password resets,
https, stopping spam bots creating accounts, users changing email addresses,
etc.)

~~~
sthlm
I completely agree with that.

Although I also think that relying on one third-party auth solution is bad.

I would propose an intermediate solution: Implement the use of several auth
solutions (e.g. like StackOverflow does). It takes some more time since ID
management won't be as simple, but it's still incredibly less complex than
implementing your own solution.

Frankly, I would happily move away from local auth solutions (except for
critical services, e.g. banking). But I don't want to entirely rely on one
account type either.

------
arkitaip
The absurd part is that some developers believe that account creation is
difficult/hard for users who are very sophisticated early adopters and privacy
conscious.

------
harel
Auth, regardless of how long it takes should be built in your app, not farmed
to 3rd parties. First fundamental building block of any app and its still, by
far, NOT the most complicated part of any website. Farming out auth to
facebook or Google should be an optional extra, not a mandatory process. I do
have a Facebook account but I rarely want to link it to anything else. I'm
still upset with StackOverflow for forcing me to use a Google account to log
in as I use google Apps which are not yet deemed Google Accounts.

~~~
harel
I take it back on StackOverflow - I can see they added a StackExchange
login... No more google logins for me.

------
davewasthere
Using FB as a login is really a usability thing more than a time saving issue.

The friction of having to choose yet another password to sign up for an
account is negated somewhat by using a FB/Twitter/Google-type oAuth/OpenID
solution.

I'm a big fan of federated login and prefer to see it on sites where possible.
But equally, I'm not sure I agree about making your site completely dependant
on FB. Although if the app also requires social graph, then they're not really
losing out all that much are they?

------
j_col
> It'll hardly take a couple of hours to write a simple login script, no?

Completely agree, makes sense to do the simple thing first, then optionally
add auth from other services later. Given that I recently nuked my Facebook
account for example, having Facebook-only auth on a site effectively blocks me
and others like me from signing up (never a good thing).

