Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

231–240 of 485 posts

Re: Why we won’t be supporting Sign in with Apple

#231
In a rat-race of adding a bunch of (Sign in with xyz) buttons everywhere in the login forms, this news feels good in a weird way. Most developers use OAuth login support using several other services to reduce the friction of signing up, but this article made me think about this for a while. I've been in a situation where I could not remember whether I signed up using a provider.

Password managers and 2FA options are getting popular in the mainstream media, and most people know about it after their financial service providers are mandating 2FA. It's probably time we figure out an easy way for users to sign in using a random alias of their email address to sign in to any service. Something that is generated using their real email address, the service provider's domain name and some kind of salting. This is the time the plain old username-password login came back.

Re: Why we won’t be supporting Sign in with Apple

#232

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

> So there's nothing specifically against Apple

The one thing that is specifically against Apple is the new App Store policy that if an app uses google/Facebook sign in, the app _must_ also use Apple Sign In.

Re: Why we won’t be supporting Sign in with Apple

#233
post #176
post #171

Earlier quoted context omitted.

Time to create a new service to unify all your SSO accounts! One single SSO!

Here comes SSSO! I can hardly wait! Of course, there may be competing SSSO solutions...

We could have a Simplified Experience Single-Sign-On, or SESSO. Italian developers would adopt it enthusiastically.

Re: Why we won’t be supporting Sign in with Apple

#234

Earlier quoted context omitted.

> Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites? Yes. Password managers exist to solve the problem of credential reuse; third-party login exists to implement credential reuse. They are fundamentally opposed.

The credentials are at least not in multiple databases and stand some chance of being more secure, so it’s not as bad as with direct credential reuse, but yes, if you do compromise that one identity provider you’re in big trouble.

With Social SSO, you essentially are passing the trust from some random company getting hacked and revealing your re-used password, onto the shoulders of internet giants like Facebook, Google, Twitter, Apple, etc and putting the trust on them, that they know what they are doing in terms of security.

I still agree that they are variants of the same fundamental problem (a single credential protects all of your logins) and that Password Managers are a vastly superior solution to this problem.

But it is worth pointing out that for the layman, using Sign in With Facebook/Apple/Google, is better than single credential re-use.

When I say "layman", I mean people like my mom and grandma. I have tried to get my mom to use a password manager (went as far as to set it up for her, and pay for it) but she just reverts to a simpler solution (which is Social SSO). If she weren't using Social SSO, she would be using her same Facebook password for every site on the internet. So as much as I personally loathe Facebook, I do trust Facebook for securing my Mom's credentials far more than the random scrapbooking website she is creating an account for. In this case, I am grateful that she is using Sign In With Facebook, even though I would never consider such an action for myself. So it is a small step in the right direction.

Re: Why we won’t be supporting Sign in with Apple

#236

Earlier quoted context omitted.

It seems sufficient to me? https://developer.apple.com/documentation/sign_in_with_apple...

Absolutely not. Compare the native ios documentation[1] with their "other platforms" documentation[2]. Their native documentation has code snippets, helpful links, and explains in depth what is happening. The "other platforms" documentation is "make this request, store some data, follow redirects". No code, no helpful links on how you might accomplish these things, nothing. You get the bare minimum. I'm not saying it…

Not surprised the documentation that highlights the Apple Platform is better, however, give.

That said, it’s a REST API you query and you get a well defined payload:

> A successful response contains the following parameters: code A single-use authorization code that is valid for five minutes. id_token A JSON web token containing the user’s identity information. state The state contained in the Authorize URL. user A JSON string containing the data requested in the scope property. The returned data is in the following format: { "name": { "firstName": string, "lastName": string }, "email": string }

I could implement this using curl really it’s that straightforward. If you have any experience consuming REST APIs

Re: Why we won’t be supporting Sign in with Apple

#237
post #228

Earlier quoted context omitted.

"all their arguments apply to all third-party sign-ons" No they don't. Other sign-on options don't obfuscate the email address. They are likely removing FB login as otherwise their next app update will be rejected by Apple for supporting third party login but not Apple login.

Obfuscation of the email address is an explicit choice by the user when using Sign in with Apple. It’s not something forced by the service. If users are choosing to do that, it says something about the lack of trust the users have with whatever they’re signing up for.

There's two kinds of "obfuscation" at play with Sign In With Apple.

One is true obfuscation - "hide my email". That would be a poor choice for use with any app you hope to have an ongoing relationship with, I'd think.

The other is just the use of iCloud email addresses, detailed in the post, which seemed like a very good and concerning point. It's also much less likely to be a problem with FB or Google login.

Re: Why we won’t be supporting Sign in with Apple

#238

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

>My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services. Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites? Sign on services from main accounts seem like security flaws. If you use one main account reso…

First of all, you need a password manager no matter what even if you use Facebook etc., because not everybody supports Facebook etc.

Second, it often still takes a lot of work to create a new account on a site, even with a password manager. Selecting a username, discovering it's taken, selecting another one, generating a random password, pasting it into a second field to confirm the password, unchecking "send me updates", going to my email to find the confirm link, blah blah blah.

If I just want to do something quick on a site (like see a Quora answer or Medium post), it can be far easier to just click "log in with Google" and see the content in 5 seconds rather than 5 minutes while you wait for the damned account confirmation email.

Re: Why we won’t be supporting Sign in with Apple

#239
Recently went through the same debacle. Our hope was that we could solely rely on Magic Link instead of email/password ... but it turns out many users don't really understand it [1]. So your options are:

1) Email/Password Sign In

2) Bite the bullet and add Apple / the "full auth stack" (FB/Google/etc.) & deal with account linking issues.

[1] https://snaphabit.app/blog/password-less-login/

Re: Why we won’t be supporting Sign in with Apple

#240
> Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time.

Holy cow, how is this acceptable to any app developer or software company? This is reason enough for me to never use Apple/Facebook/Google sign-on as a developer -- huh, or even as a user. Apple/Facebook/Google could lock out all your users and literally destroy your business in a split second for an arbitrary policy violation, without explaining why, with no way to contact a human being. Haven't we seen enough HN headlines where an independent developer or a small software company is begging for help because canceled their account or locked them out of something with no recourse?

EDIT: I know that AnyList is dependent on Apple's app store. This is still no reason to give Apple (or Google or Facebook) even more power over you.

Post reply on HN