6 ms·

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

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.

ShakataGaNai 7y ago
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.
- shadowgoat 7y ago
  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.
cmroanirgo 7y ago
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)
- tmarman 7y ago
  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...”
  - godzillabrennus 7y ago
    Would make sense to create package for popular mvc frameworks that does this.
  - badtuple 7y ago
    This seems like a nice user experience, but I'd be worried about leaking which email address has an account with us.
    - Nextgrid 7y ago
      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?
    - nevi-me 7y ago
      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
- ec109685 7y ago
  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.
NightlyDev 7y ago
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.
- jedberg 7y ago
  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.
- mr_toad 7y ago
  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.
pedalpete 7y ago
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.
- skylarchunk 7y ago
  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.
- xenospn 7y ago
  Same! People log in again after a few weeks/months and can’t find their stuff.
somishere 7y ago
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.
- Operyl 7y ago
  The user is given the choice to use their email, or a proxy email, in the modal that Apple provides on the system side.
  - Twisell 7y ago
    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.
8ytecoder 7y ago
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.
m0dest 7y ago
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.
- DerJacques 7y ago
  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.
  - earenndil 7y ago
    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.
    - deleted 7y ago
      [deleted]
    - Sleidom 7y ago
      test
  - dwaite 7y ago
    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.

ShakataGaNai 7y ago

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.

shadowgoat 7y ago
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.

cmroanirgo 7y ago

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)

tmarman 7y ago
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...”
- godzillabrennus 7y ago
  Would make sense to create package for popular mvc frameworks that does this.
- badtuple 7y ago
  This seems like a nice user experience, but I'd be worried about leaking which email address has an account with us.
  - Nextgrid 7y ago
    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?
  - nevi-me 7y ago
    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
ec109685 7y ago
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.

NightlyDev 7y ago

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.

jedberg 7y ago
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.
mr_toad 7y ago
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.

pedalpete 7y ago

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.

skylarchunk 7y ago
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.
xenospn 7y ago
Same! People log in again after a few weeks/months and can’t find their stuff.

somishere 7y ago

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.

Operyl 7y ago
The user is given the choice to use their email, or a proxy email, in the modal that Apple provides on the system side.
- Twisell 7y ago
  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.

8ytecoder 7y ago

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.

m0dest 7y ago

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.

DerJacques 7y ago
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.
- earenndil 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - Sleidom 7y ago
    test
- dwaite 7y ago
  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.