> I would definitely stay away from any "Sign in with Apple".
I would stay away from any "Sign in with.." service as a user and as a product owner. You're affectively giving away a major control of your users to a third party.
I would stay away from any "Sign in with.." service as a user and as a product owner. You're affectively giving away a major control of your users to a third party.
And as a user, why would I trust my password to the website that rolled their own authentication over the big companies?
Do you use the same password everywhere, by any chance? :)
Thankfully, it's still fine for my bank login.
And as a user, what if Facebook/Google/Twitter/Apple decides you've violated their ToS, blocks you from your account, and now you can no longer log into any of the sites you've linked with one of those providers?
I know this is a bit extreme, and for many people, the risk is totally worth the reward, but I think that is one of the chief concerns many people have with trusting a third party for all their sign-ins. It's a single point of failure.
Other people have mentioned this, but if you're not reusing passwords, this shouldn't be a concern for you. Don't reuse passwords!
On the security front, companies that are implementing 3rd-party sign-in can still get hacked and leak your personal information. If that information is supplied by Apple instead of you, it's all the same. You don't automatically get better security because you're using 3rd-party sign-in, you only get better security if you're being forced to stop doing something bad (reusing passwords, enabling 2FA) or if Apple is providing less information than an account would ask for during signup.
To Apple's credit on that front, they do mask your email, which is a legitimate privacy improvement. But it would be better for that to be a generic service that allowed you to generate an anonymous email at any time for anything, rather than a perk that's hardwired into an anti-competitive scheme to make it harder for you to migrate devices or change services.
This situation is solvable by implementing forget password and storing user's email but many services don't and with a system similar to apple's where you mask the email or phone number, you can't do anything.
Even if the local auth system was poor, an email/password combo is simpler and faster without leaking data to social providers. There's no reason to remember which provider you used, or login to them first, or worry about loose permissions especially with future changes. It also limits the blast radius in case your social account ever gets compromised, and it's useful for completely anonymous and disposable accounts.
It's similar to publishing on medium (or Huffpost, from a few years ago) as opposed to your blog. You'll get more reach in the former case, but have much less control. For that matter, it's similar to serverless vs code everything and host it in a server on a rack somewhere.
Engineering is all about the tradeoffs.
So, how would I make that call? I'd think about how much it mattered to have control of the auth experience vs the easier onboarding of customers. I'd think about the risks of having the auth yanked out from under me (I'm not aware of any cases where this happened). I'd think about the value add of auth to my app; in most cases it's slim to none. I'd also look at what the auth provider allowed me to know about the user when they deliver an authenticated user to my application.
I think in general auth isn't a huge differentiator for most applications, and offloading it to a social provider, as long as a chunk or most of the target market has an account (github for devs, linkedin for sales folks, google for, well, people with an email address), is a good choice.
Don't forget, you can provide both; I've worked at companies with only social login, but don't think that's very common.
Disclosure, I now work for a company which provides auth software (link in my bio).
It's more expensive than syndicating content, sure, but I think you want to compare the relative costs of each option, not between them.
Write on medium vs writing on your own blog
Using social sign on vs building your own auth system (hopefully using a library)
But as long as that service has quality 2FA options with (ideally) Webauthn, it's much less of a concern.
You may also get users that you wouldn't have otherwise. It's a trade-off. Lowering friction tends to increase conversions.