I think "Sign in with Apple" is unique that Apple allows the users to hide their email address https://support.apple.com/en-us/HT210425 which makes it extremely hard to migrate away, unlike other federated login system where you can at least get users' email addresses, allowing you to create a proper email+password login later on.

I think it is very private. The third party app cannot sell the attached email address to others. But I agree if you sign up with the third party using your apple id, they will not know you which may end up in creating second account. If they don't have account linking feature, it will be messy.

Apple announced an account linking feature as a requirement at WWDC this year.

How is that? It's the developer's choice of they want to let me add a second login to the same account.

As a product owner, why wouldn't I want to piggyback on the millions of dollars of R&D + security that the big companies have put in?

And as a user, why would I trust my password to the website that rolled their own authentication over the big companies?

> why would I trust my password

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.

As a product owner, because what if that service provider decides to (mis-?)interpret something you did as against their TOS and revoke your access to their sdk, thereby making it more difficult for many of your users to log in?

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.

> why would I trust my password...

Do you use the same password everywhere, by any chance? :)

I used to, but some websites stopped accepting "abc123"!

Thankfully, it's still fine for my bank login.

As a user, I recently deleted x account. I used login with x on a few services and now I can't access them anymore.

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.

this is a MASSIVE selling point, BUT, when your users contact support trying to gain access to their account and can't describe what their email address might be... trust me, there is pain in your future.

Users can just tell the vendor what their real email address is when they want support, until Apple bans vendors who ask for contact info.

It's true that oauth is very secure but I wouldn't assume major sites are rolling their own authentication. The standard password hashing methods and workflows are all well known and implemented.

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.

Well one issue as a user is trying to remember which third-party auth was used when I first created the account (did I use Facebook? Google? Twitter?).

Well, you can get access to the email on all three so it's not a huge problem for vast majority of whom only maintain single email address.

Mainly to prevent the big companies from knowing every website you’ve ever visited.

This is always a business decision, imo.

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 extremely cheap to syndicate to Medium plus other venues. Not so for Sign In With.

What is expensive about "sign in with"? There are lots of libraries that will make it pretty simple, though the configuration can be hairy (google, looking at you).

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)

As a user, I'm much happier giving my e-mail address to Apple who already has it, then 100 other websites.

I always leaned that way, but from the security and compliance side of things it's a heck of a lot easier for us when our staff can sign into 3rd party services with their company Google account that has strict security and 2 security keys in place vs whatever the luck of the draw may be with each service that we want to use. It's a nice alternative to the "SAML SSO only available with $10k / user enterprise account" routine.

But as long as that service has quality 2FA options with (ideally) Webauthn, it's much less of a concern.

so, if you're a service that posts memes to twitter, or facebook you should always use email and sms two factor, no 'sign in with facebook/twitter' links?