5 ms·

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

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

yegle 6y ago
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 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.
- the_arun 6y ago
  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.
  - dkonofalski 6y ago
    Apple announced an account linking feature as a requirement at WWDC this year.
- gowld 6y ago
  How is that? It's the developer's choice of they want to let me add a second login to the same account.
gremlinsinc 6y ago
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?
KMnO4 6y ago
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?
- xenocratus 6y ago
  > why would I trust my password... Do you use the same password everywhere, by any chance? :)
  - ethbr0 6y ago
    I used to, but some websites stopped accepting "abc123"! Thankfully, it's still fine for my bank login.
- ts330 6y ago
  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.
  - gowld 6y ago
    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.
- chrisshroba 6y ago
  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.
brightball 6y ago
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.
Angostura 6y ago
As a user, I'm much happier giving my e-mail address to Apple who already has it, then 100 other websites.
outworlder 6y ago
> You're affectively giving away a major control of your users to a third party. You may also get users that you wouldn't have otherwise. It's a trade-off. Lowering friction tends to increase conversions.
mooreds 6y ago
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).
- gowld 6y ago
  It's extremely cheap to syndicate to Medium plus other venues. Not so for Sign In With.
  - mooreds 6y ago
    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)

yegle 6y ago

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

the_arun 6y ago
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.
- dkonofalski 6y ago
  Apple announced an account linking feature as a requirement at WWDC this year.
gowld 6y ago
How is that? It's the developer's choice of they want to let me add a second login to the same account.

gremlinsinc 6y ago

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?

KMnO4 6y ago

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?

xenocratus 6y ago
> why would I trust my password... Do you use the same password everywhere, by any chance? :)
- ethbr0 6y ago
  I used to, but some websites stopped accepting "abc123"! Thankfully, it's still fine for my bank login.
ts330 6y ago
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.
- gowld 6y ago
  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.
chrisshroba 6y ago
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.

brightball 6y ago

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.

Angostura 6y ago

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

outworlder 6y ago

> You're affectively giving away a major control of your users to a third party. You may also get users that you wouldn't have otherwise. It's a trade-off. Lowering friction tends to increase conversions.

mooreds 6y ago

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).

gowld 6y ago
It's extremely cheap to syndicate to Medium plus other venues. Not so for Sign In With.
- mooreds 6y ago
  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)