Using Social Networks as an Identity Provider

SDO Marketing Staff | July 25, 2018

One of the major innovations in authentication today has come through harnessing our social accounts as identity providers.

Utilizing our social applications to confirm our identities has certainly streamlined access to tools and services.

Data has shown that nearly all users have at one point encountered a social login option, and about half use them regularly.

The question is: what is being sacrificed for this convenience?

How it Works

Using social apps as a login medium essentially turns these accounts into identity provider servers. This allows the requester (i.e., the service you’re trying to access) to connect to another service provider that the user is already signed up for. The most common solution used to make this “connection” is the Auth0 platform. Auth0 supports all of the big names in online services from LinkedIn to DropBox. Auth0 works by providing authentication “tokens” to the requesting app. These tokens function a bit like your username and password since at the end of the day, they give the requesting app access to a password-protected service–say, your Facebook account for instance.

There is one crucial characteristic of this granted access: the actual username and password to your social account are never actually communicated between the apps directly. The requesting app only gets a limited “peak” into the password-protected account–enough to confirm who the account belongs to.

There are certainly some advantages to the social login model.

Social logins are backed by the biggest and most resourceful tech companies in the world. When you use your Google account login to a service, for example, you’re basically capitalizing on Google’s infrastructure to secure the authentication.

The Double-Edged Sword

Despite the security and added user experience that comes with social logins, there are a few caveats to this authentication method.

The security of a social login depends entirely on the security of the account it’s utilizing. If a hacker succeeds at compromising a social account, they’ll also gain full access to all the corporate apps linked to the same account. Considering the danger posed to these accounts from social engineering scams, this adds a considerable layer of risk to social logins. Once compromised, the account function as a “social  SSO.” If a hacker gets ahold of, say, a users Google credentials and use them to login to Chrome, a quick glance at will show the thief all the applications linked to the Google account. The same applies for a breached Facebook or Linkedin–the “settings” tab on both these sites will show which online tools are connected to a given account.


This risk becomes even more serious when considering things from an organizational perspective.

Social logins are personal, which means that as an organization, managers have no way to support them systematically–or manage their security protocols. The entire burden of securing corporate accounts linked to social logins rests on the shoulders of the individual users. This means it will be up to them to select strong passwords, enable multi-factor authentication on their accounts, and avoid the ever-present pitfall of cross-using passwords.


It was because of these risks that industry leaders have labeled social logins as less trustworthy than corporate identities. Analysts at Gartner have urged enterprises to implement trust elevation for high risk access when relying on social account-backed authentication.

Reclaiming your Authentication

Instead of spreading authentication across the individual social media accounts of employees, companies can centralize their authentication protocols with strong identity services, either cloud-based, or oon-premise platform.

There are important benefits of contracting an Identity Access Management (IAM) service. Having an effective service provider enables enforcement of the full range of security policies across an entire enterprise, and in the case of cloud service, it also eliminates the need to acquire supporting hardware. At the same time, IT departments are often able to customize protocols according to need and minimize friction from a user experience perspective.