Why don't some services offer Google/Facebook/Apple/Twitter login

Question

Why don't some services offer Google/Facebook/Apple/Twitter login? Namely Crypto exchanges.

I assume they want as many users as possible & this is a great way to get more. Is there some sort of security vulnerability associated with them?

Edit: For Google & Apple login since both offer email services (gmail & icloud), offering the login button for these is the same thing as asking them to verify their email address. Assuming all you do on the login buttons is get the verified email address (which is all you need). Of course you'd still want 2FA

Answer 1

There are a variety of reasons that a company may not want to offer a federated login option. Some of them include the following:

• People don't necessarily protect their social media accounts very well. A company may want the ability to require a strong password or 2FA to log in, and that's harder to do when you use a third-party login. Also, services may not want the compromise of your social media account to be a compromise of their account.
• Some third-party login providers provide access to email addresses, and some don't. Apple uses a custom email. For situations where a service needs access to an email, whether for reasons of identity (e.g., GitHub and associating commits with accounts), fraud and abuse prevention, or less ethical reasons (e.g., non-confirmed opt-in marketing or other types of spam), a third-party login may not be sufficient.
• Depending on the way the third-party login provider works, you may end up with only a username, or a fixed ID as a result of the login information. If you store the username and not the ID, then you have a problem if the original owner deletes their account and someone else creates one named the same thing. If you don't implement third-party login, this doesn't happen.
• In the specific case of cryptocurrency exchanges, typically you are going to have to provide some sort of financial information to conduct business, and often additional information for local know-your-customer requirements. In many jurisdictions, these laws are very strict. Since you are already providing a good deal of information, much of which is quite sensitive, a custom username and password wouldn't be seen as very burdensome.
• Some services are highly regulated and must meet audit requirements, such as those from companies working in the financial industry or those selling to governments. These audits take a long time, involve a lot of personnel, and tend to be extraordinarily expensive. Adding third-party login increases the scope of the audit and makes other people's security or compliance problems the company in question's problems, and they would like to avoid that.

Of course, these are some general reasons. Individual companies may have other reasons, but we have no way of knowing what they are.

Answer 2

In addition to the excellent reasons already mentioned in the other answer:

• Single sign-on / federated authentication means the identity provider knows what site/service you're signing into, and when. Lots of people might not want Google or Apple knowing about every site they sign into, and in particular might not want that information exposed when using cryptocurrency. Obviously if e.g. Google is also your email provider, then any emails the service sent to that address will reveal that you're talking to them, but unless the email provider is parsing your email closely, they won't have as much information as seeing exactly when you sign into the cryptocurrency exchange would provide.

Answer 3

Tackling this from an engineering perspective, it’s not necessarily trivial to provide third-party login services. OAuth2 does make it easier, but you can’t technically just slap a login button on your page that links through OAuth2 (or whatever other federated protocol) and not have to do anything else.

For example, Google actually has some pretty specific requirements for how their login button should look, where it should be placed, and a slew of other things as well. To actually abide by their ToS as a third-party service using their SSO functionality (and thus not get hit with litigation or blocked from using their sSO functionality), you have to meet all those requirements and not be doing something they deem unacceptable to be associated with (or possibly consider to be direct competition with one of their services).

Pretty much all major SSO providers have similar requirements as well. In general, these are usually not extremely difficult, but some sites may not consider it worth the hassle (or they may be snobs who refuse to accept the stylistic aspects required by the SSO providers).

Each provider also provides slightly different sets of info which will have to be normalized for your own account database, and depending on the specifics, you may even have to deal with different protocols.

---

Even aside from the engineering aspects, there’s the public image aspect. For example, a company that prides itself on being ‘All American’ probably does not want to list Yandex or Alibaba as a SSO provider, as those companies are very much not American and that might hurt their image with prospective users.

Answer 4

To extent CBHacking's point, the privacy issue is not just for people using this to sign in (which can be considered acceptable since using the federated login can be optional/users can choose which provider to use) but sometimes even affect users who intentionnally avoid it.

E.g. Google strongly recommends their client library which always sends personalized requests to Google to check if you are already logged in etc. For people who want to login using Google this is not an issue, but other users might not want to send the information which site they are visiting to multiple identity providers they don't have any association with.

Even if this is avoided by not using the APIs (which further increases the effort to implement this), the presence of standardized buttons might give your users the impression that their data is sent to these companies.

Answer 5

I can think of a few reasons:

• SSO means that it is the SSO provider that says who your users are. Technically they could deny legitimate users or impersonate them. Obviously there are legal barriers that prevent the providers from malicious use of this power but there is some risk in externalizing user authentication.
• A cryptocurrency exchange might also face claims that some operations were not executed by the owner of an account. If you manage authentication internally you have all the useful information but with an external provider there might be problems in acquiring the data relative to an incident.
• The SSO provider might have terms and conditions that are not compatible with the terms and conditions you intend to offer your users. See for instance the above case of denying an operation.

Answer 6

In addition to @CBHacking and @bk2204:

• The service provider may not want to be bound by the Apple/Google/Facebook conditions for doing business or technical requirements.

E.g. crypto and porn are particularily vulnerable to third parties changing rules behind their back, but others periodically suffer as well. And a minor API change may be a nightmare on its own for everyone.

It is bad enough that the payment processors and the ad networks (either of them important for a typical web service business model) do basically whatever they want, periodically breaking things.

One more third party may be too much.

Answer 7

Also, remember that having these services enabled also most of the time doesn't allow you to customize your profile on the service. Less of a security issue than a customization one... but still there.

Answer 8

Some websites would still need a Signup form as there are other details that needed to collect from customers. For example, a website I used to work on, was legally required to have the customer accept their terms & conditions before creating a user account.

In these cases, having a Google login will eliminate 3 fields(name, email & password) from the form and replace it with a redirect and back to a Google website. Not as good as the cases where the form can be eliminated completely.