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

  • 55
    It's in the backlog Commented Aug 25, 2021 at 17:47
  • 35
    Because handing total control of your supposedly-private finances to Apple, Google or Facebook is a great idea. What could possibly go wrong? Good grief... Commented Aug 26, 2021 at 6:20
  • 4
    @Shadur with that logic they wouldn't allow gmail or icloud email accounts. Plus all well known crypto exchanges require 2FA so it's not like this sign in button would give them a backdoor.
    – Trevor
    Commented Aug 26, 2021 at 6:35
  • 2
    What if one day the external provider fallen? How would they deal with orphaned users? External login providers should be used only as a secondary option (besides domestic), if at all.
    – Trang Oul
    Commented Aug 26, 2021 at 9:32
  • 9
    You can't log into your online banking with a Facebook account either... largely for the same reasons.
    – J...
    Commented Aug 26, 2021 at 18:38

8 Answers 8


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.

  • 4
    There are many good answers in this thread, but in my opinion your first bullet is the most serious concern. Social account takeover is pretty commonplace and a crypto exchange would not want a user's wallet cleaned out because they reused their Facebook password. Commented Aug 25, 2021 at 20:41
  • 33
    This - I wouldn't trust a bank that lets me log in with a social media account.
    – Criggie
    Commented Aug 25, 2021 at 23:26
  • 15
    @NateBarbettini: The frustrating thing is, my Google account is way more secure than my bank account. The bank is still using 1FA backed up by security questions, and that's pretty much the same for every US bank.
    – Kevin
    Commented Aug 25, 2021 at 23:55
  • 6
    I suppose you could argue that Google is a "social media account" (maybe less so with the death of Google+), but given the prevalence of using Gmail and of password-reset-confirmation-by-email systems, systems effectively are only as secure as users' Google accounts anyway.
    – jamesdlin
    Commented Aug 26, 2021 at 1:01
  • 1
    I tried to assume a diligent, thoughtful service provider making deliberate decisions, which would necessarily exclude laziness. Anyone dealing in finance, whether traditional or cryptocurrency, is going to need to be thoughtful and prudent about their design decisions or they're going to find themselves in a lot of legal trouble.
    – bk2204
    Commented Aug 26, 2021 at 1:57

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.
  • 3
    This is a reason a user might not use this feature when offered. It's not really a reason for a site not to offer it, which is what was asked. Commented Aug 25, 2021 at 22:26
  • 10
    @BlueRaja-DannyPflughoeft it is: If I would consider something as sensitive as a banking site, them having facebook on the page would count as a big con-argument for me. A bank that knows that will weigh that against any such decision. I feel that my sentiment is not too rare in geeky tech circles. And crypto companies historically come and target that sector (yes now they broadened their target base quite a bit). Commented Aug 26, 2021 at 2:36
  • 3
    @BlueRaja-DannyPflughoeft This is absolutely a reason for a site that cares about security and understands that entirely too damn many of its potential users are going to be lazy idiots about it not to offer them the option. Commented Aug 26, 2021 at 6:22
  • 1
    Also Google or Apple might not want you to use them to sign into certain sites. Consider how credit card companies threatened to cut off services to OnlyFans because they don't like sex work. Maybe your site isn't sex work, but you still have the same threat from any third parties you rely upon. Commented Aug 26, 2021 at 11:47
  • @FrankHopkins I understand some users might feel this way, and that might be a good enough reason for them to not provide it. But the actual logical argument behind objecting to companies just offering the service seems weak at best. That appears to come down to distrusting any service that doesn't also distrust Google. But to be logically consistent you'd also need to distrust anyone who doesn't also distrust those services, and anyone who doesn't distrust those people. Taken to its logical conclusion, you wouldn't be able to trust anyone at all.
    – NotThatGuy
    Commented Aug 26, 2021 at 12:42

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.

  • 11
    And in addition to the initial implementation cost, every additional feature offered by your web application also has ongoing costs: Customer support, updates (the SSO provider might change the interfaces), training for new developers, maintenance, unexpected interactions with other system components, etc. Whether the additional customers you get by offering SSO is worth that cost is a business decision.
    – Heinzi
    Commented Aug 25, 2021 at 13:04
  • 1
    @Heinzi Yep, and that’s exactly why the company I work for has not added any SSO support to our web app other than GitHub and Google. Social media makes no contextual sense (it’s a business oriented application), we don’t have Windows support for the client software (so a Microsoft account makes little sense), and our macOS support is not great (so Apple also makes no sense). Commented Aug 25, 2021 at 13:07
  • This is definitely the correct answer. The other answers are vastly overestimating the security knowledge of the average web developer. Commented Aug 25, 2021 at 22:31
  • @BlueRaja-DannyPflughoeft I’d argue that a lot of the other answers are approaching this more from the perspective of a PM than a developer. Commented Aug 26, 2021 at 0:13
  • 1
    While other answers are reasonable excuses that a site operator might give, this is probably the real reason in most cases.
    – barbecue
    Commented Aug 26, 2021 at 16:27

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.


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.
  • 1
    This is a great point. One of the advantages of SSO for many companies is the ability to impersonate customers/staff for support purposes.
    – barbecue
    Commented Aug 26, 2021 at 16:29

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.

  • 2
    This is the #1 reason for the vast majority of companies. You do not want to be at the mercy of a random Google employee deciding to ban your service overnight. Its also why Play/App store are the epitome of evil, as it gives full control over your destiny to two corporations. Microsoft couldn't even dream of such powers in their heyday. Commented Aug 27, 2021 at 23:50
  • And not just that, what if I create an account with you linked to my twitter account and next week twitter decides they don't like something I retweeted and ban me? (yes, this happened to me, at least the second part). I now have no more access to my account with your company.
    – jwenting
    Commented Sep 1, 2021 at 9:34
  • @jwenting yes, the user is at even worse position. A service provider has some leverage against the Big brother - a contract, or at least the possibility of the lost profit. An ordinary user has either some hard to enforce law-mandated rights, or nothing.
    – fraxinus
    Commented Sep 1, 2021 at 10:15

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.

  • Welcome to SSE! So, the main goal of offering this feature should be to get users in the door. You just need to verify their email via the sns button. Rather than make them open their email themselves, find your email, click some link or copy a code & then come back to your site. You can still have all the customization you want on your own service.
    – Trevor
    Commented Sep 2, 2021 at 2:05

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .