Why we had to deprecate social login support

You may be wondering about exactly what problem we’re trying to solve with that decision, because some people really enjoy the simplicity and convenience of logging in with their social accounts.  Social Logins seemed like such a good idea years ago when they started to become available. It was easier for users to not have to remember a separate username and password for each site, and developers didn’t have to worry about properly encrypting and protecting users’ passwords. Just grab the appropriate credentials from their validated Facebook or Google logins and let them in. Then a few things happened:

• Facebook started to fall a little out of favor/fancy with many users, who preferred to use Google or Microsoft for their logins.
• Apple rolled out their social login support, and required that developers of mobile apps support their Apple ID if they ware going to support any other social login provider.
• Users started to lose track of exactly which provider they used for each site. So they’d have to try a few of them each time, and the error messages they got didn’t necessarily help them determine which provider they used.
• Password Managers made it much easier for users to track different usernames and passwords on multiple sites.
• There was some fear/discouragement of putting all your eggs in one basket (e.g. if somebody got your Facebook password, they could log into any of your social accounts), so people wanted to use social logins less.
• If they used the wrong provider, sometimes they created multiple accounts on the site they were visiting.

Then Apple introduce their Private Relay feature, under the premise of protecting users’ privacy, but it’s had three horrible consequences for users:

1. They don’t know their email addresses for the sites where they used the private relay, so when they reach out to any customer service email (e.g. for help logging in), there is no easy way to look them up because they never know their email (which is in the format of somecrypticstring@privaterelay.apple.com). This has proven to be extremely frustrating for our users and customer support team.
2. They might forget if they previously created an account, or which provider they used, so they used Apple’s Private Relay and created another account.
3. If they use their email with any business that has a brick-and-mortar function (like an exercise studio), they can walk into a class and we’re unable to find them or look them up. Emails are unique and easy to find. Names are far less so.  Coupled with #2 above, some people would show up with two accounts, but their purchase was associated to the private relay account, and an old membership account with email had no credits/purchases associated with it.

The last point was extremely frustrating to our franchisees and members, so we stopped the creation of any social logins. Now of course you can ask for their first and last name and other identifying information, but the Apple experience in particular allows the account creation to happen prior to getting any other details, so any error during sign up and the account creation process was thwarted.

We could have interrupted the sign-up flow and told the user that they used a private relay to sign up, and we’d never be able to help them with customer support inquiries, but that’s a disruptive flow, it’s more coding to design, implement, and support, and we weren’t sure if it would run afoul of any Apple policies if we stopped users from allowing their private relay signup.

Now stopping social support doesn’t completely solve it, because in some instances Safari will automatically set you up with a private relay email address, so the only option in this case is to either interrupt that flow and disallow it, or email the user their login/support information and code around it.  This also is a very good reason why you shouldn’t ever use an email address as the ID of a user, and never allow the association of only one immutable email address with a users.

There’s one other giant use-case for not supporting social logins at all. We learned it when we tried to integration with a third-party platform and support single-sign-on for our users (becoming the OAuth provider). They had to refer to our login system to work (which was Cognito, which is a whole other problem), and then we needed to rely on them to make sure they supported the specific requirements of Google, Facebook, and Apple through the web view that they used for login. And their application did not, because it didn’t need to until they were asked to use a third-party OAuth provider. They updated their code eventually, but it took a disproportionately long time to get them to acknowledge the problem and then roadmap and implement the feature support.

Long-story short, if you can see a future where you will be an OAuth provider, or a future where you’ll have a brick-and-mortar experience for your users, or a situation where you provide human customer support through email and not embedded entirely within app (which is paradoxical if they can’t login and don’t actually know their private relay login information), then you may want to consider not implementing social login support. Just remember to make sure your username and password fields are auto-fillable by password managers so you don’t needlessly frustrate users.