Hacker News Reader

Comment by shadowgoat | Hacker News Reader

Haven’t done anything with Apple sign in, but I worked with a lot of other providers before. If you have multiple options, users might forget what service they used. This becomes an even bigger problem if the paid for a service with a different provider and can’t find their purchase. If you do use something like this, only having one provider (only Apple) makes things less confusing.

View on HN

I worked on the design and rollout of multiple sign in providers on a popular app. There are best practices that avoid these issues (users forgetting which service they used), but they are rarely implemented.

The trick is to be very forgiving: If a user tries to sign in using provider X, and we discover an email address conflict with an account that uses provider Y, we would simply ask users to confirm by clicking a button to sign in with provider Y. From that point forward, both provider X and provider Y can be used to sign into the account.

So many apps miss the importance of this and cut corners by only allowing an account to be associated with 1 sign-in provider, or forcing users to create passwords for these accounts, or differentiating between login and signup.

Interesting. Wouldn’t that allow someone to sign up for service Y with an email address associated with an account in your system using service X, in order to get access to the account in your system?

Maybe there’s something I’m not seeing, but it seems dangerous to rely on the identity provider’s email address to authenticate the user.

It's assumed that, if you're signed up for a service with an email address, you control that email address.

This is generally a reasonable thing to assume, and can be verified for whatever account providers you support.

Your local account is associated with X, you attempt to sign in with Y, the Y authentication was successful but there is no local account associated with Y.

Some heuristics (such as email address matching) means you indicate to the user that perhaps they meant to try X? They sign in with X, and now you have authentications from X as well as Y for the user.

You use the authentication from X to authenticate, and you associate provider Y with the account as well. From this point forward, either X or Y can be used. You might also indicate these on a user profile page, possibly with other options - the user may decide they want to either revoke authentication from X or Y or add on authentication with Z.

You also have a similar behavior with multiple authenticators if you are implementing Web Authentication/FIDO, however these are "pure" authentication with no attributes so your heuristics for this sort of pre-login suggestion would be limited.

Exactly this.

This. I'm not a big user of SSO in general, but on the few sites that I did use it, I'd forget whether I used SSO or not. Also, using SSO locks you into using that vendor. I've a couple of accounts that I'd like to change to normal uname/pwd but am locked into the SSO vendor (which I'm hoping to move away from)

On all sites/apps I’ve built offering SSO, we’ve gone out of our way to support linking of accounts and detecting existing accounts when claims like emails are found. Also allowing for merges after the fact.

I would consider this a best practice when iffering any “ sign in with...”

Would make sense to create package for popular mvc frameworks that does this.

This seems like a nice user experience, but I'd be worried about leaking which email address has an account with us.

Wouldn’t the sign in mechanism (which validates e-mail) prevent this, in the sense than they won’t be able to get a third-party account to authenticate with for a particular e-mail without verifying ownership of that e-mail to the third-party provider?

You address this by only linking accounts once a user has successfully signed in with another provider. That way if their email exists from another provider, you're more certain that it's the same account

No it doesn’t. All the SSO providers (besides Apple in some cases) provide a verified email address to the site that can use to dedupe.

We have the same problem, it's probably our 3rd biggest support issue. "Where's my stuff??"

We offer only Facebook, Google, or Email. People see the email box and start typing in their email, they forget if they signed in with Facebook or Google previously.

I'm surprised it isn't the other way around. Of course, this wasn't an issue before we added email, but we got a bunch of requests from people who didn't want to sign-in with Facebook or Google.

We still have about 70% of our users who sign-in with social providers, so I'm not completely sure it was worth the headache.

It feels to me that Apple affords the benefit of Facebook, in that users do not anticipate asking "where's my stuff". But the added benefit is the perceived security and reliability of Apple.

Same! People log in again after a few weeks/months and can’t find their stuff.

It's fairly straightforward to let them work interchangeably ... We run FB, Google and passwordless email for login. It doesn't matter which you use, email address is the uid between them. Obvs where a common email address hasn't been used (or isn't available ... does apple login use their proxy emails?) this becomes an issue.

The user is given the choice to use their email, or a proxy email, in the modal that Apple provides on the system side.

Which is in retrospect is a good move as more than one people here casually explained that they aggregated identities from different third party at login for convenience... I'm not really sure this kind of behavior is RGPD compliant.

Not familiar with latest sso implementation but what happen if base email used with a third party change. Does your token get revoked or does it persist? If so you can now detect that foo@aol.con is the same person than bar@gmail.con which is valuable information for dubious data broker.

Doesn't most services just create an account like normal when you sign in with eg. Google, if the email is verified? Then you can just use the forgot password and use your mail to log in without Google even if it was created with Google. At least that is my experience.

I've definitely been stuck in a loop where it said that I signed up with Google and must use Google to sign in when I tried to use my email to reset my password.

No, if you sign in with Google you don’t have a password. There is nothing to forget, or reset. That’s the whole point.

Yes, that is a problem. If your app/site supports multiple login options you may have users who "lose" their account (I'm one of them).

However your solution... doesn't work. Apple requires apps that support social app to have sign in with apple. Google has similar requirements (because your app better be multi-platform in this day in age). Facebook is way popular. So that's three right there.

If it was my app, I wouldn't use any. My recommendation only shows how out of touch I am with social providers since I haven't touched them in probably 4 years. Thanks for the heads up with the Apple and Google requirements.

Second that. We analyse where our users are coming from across all channels and added only that. This made it really easy for the users to both remember what they used and also to sign up/sign in almost instantly.

Reply on news.ycombinator.com