2 ms·

I have a B2B app. It allows Google Sign-In only. My last B2B app was the same. Nobody complained. Understand your audience. If you can just go with something l

I have a B2B app. It allows Google Sign-In only. My last B2B app was the same. Nobody complained. Understand your audience. If you can just go with something like Google, do it; you'll save a ton of time and can focus on developing features your customers are willing to actually pay money for. Authentication method is not usually a value proposition. Only implement multi-service auth as a last resort. It's great for mass-market consumer apps, but the development workload is significant and you will end up with a support workload for merging accounts no matter how clever your implementation is.

sebleon 9y ago
> development work is significant Not true, these guys invested a lot in making their sdks easy to integrate. You should be able to have fb/twitter/Pinterest/etc login in an afternoon
- hamstercat 9y ago
  Parent is talking about the time it takes to integrate multiple ways to login, and I agree with him. When you implement only one way (be it social login with Google/Facebook/etc or an email/password combination depending on your target audience) it's usually easy. When you have multiples ways to login, you end up having to (1) maintain more code, but also (2) need a way to reconcile users who end up signing in with multiple methods.
  - smaudet 9y ago
    'Maintaining more code' is code for 'I can't write code/I am drowning in unrelated problems/I am just plain lazy' Its a fine philosophy to apply to an entire project where you may talking tens of thousands of lines vs thousands vs hundreds. It doesn't apply to a situation like this, where you are talking perhaps a few hundred lines, tops. If you are doing it right, I wouldn't think you are implementing much more than a thin wrapper around an existing login provider. There are so many valid open source implementations of this out there, this should be zero issue from a maintainabilty/testing perspective.

sebleon 9y ago

> development work is significant Not true, these guys invested a lot in making their sdks easy to integrate. You should be able to have fb/twitter/Pinterest/etc login in an afternoon

hamstercat 9y ago
Parent is talking about the time it takes to integrate multiple ways to login, and I agree with him. When you implement only one way (be it social login with Google/Facebook/etc or an email/password combination depending on your target audience) it's usually easy. When you have multiples ways to login, you end up having to (1) maintain more code, but also (2) need a way to reconcile users who end up signing in with multiple methods.
- smaudet 9y ago
  'Maintaining more code' is code for 'I can't write code/I am drowning in unrelated problems/I am just plain lazy' Its a fine philosophy to apply to an entire project where you may talking tens of thousands of lines vs thousands vs hundreds. It doesn't apply to a situation like this, where you are talking perhaps a few hundred lines, tops. If you are doing it right, I wouldn't think you are implementing much more than a thin wrapper around an existing login provider. There are so many valid open source implementations of this out there, this should be zero issue from a maintainabilty/testing perspective.