The ​Akamai Control Center​ Identity Cloud (under the name of its predecessor, Janrain) played a key role in developing, implementing, and popularizing the idea of social login. With social login, a user who wants to create an account on your website doesn’t have to do so by coming up with a new username and a new password specifically for your site. Instead, the user can create an account for your site based on an existing account they have with a social login identity provider such as Facebook, Twitter, Google, or LinkedIn. This enables the user to log on to your website by logging on with, say, their Facebook account. In turn, that means that the user doesn’t have to remember yet another username and yet another password, something that helps keep the user experience about as friction-free as you can get.

As you might expect, many organizations have enthusiastically embraced social login: after all, anything that makes the user experience less painful is almost-always a good thing. In fact, if there’s a drawback to social login it’s not because organizations don’t find it useful; instead, it’s because social login has largely been dictated by the various Customer Identity and Access Management (CIAM) providers. For example, the Identity Cloud currently enables you to use 30 or so different social login identity providers (IdPs), including such “heavyweights” as Facebook, Twitter, Apple, Google, LinkedIn, and Salesforce. That’s par for the course; other CIAM providers have their own list of IdPs you can use and, for better or worse, a much longer list of IdPs that you can’t use.

That can be a problem if your organization was hoping to use, say, Okta as an Identity Cloud social login identity provider. Granted, it’s never been impossible to use Okta as an Identity Cloud social login provider; however, to do that has always required a separate development project driven by ​Akamai​ (and paid for by you). And if you also wanted to enable logins using Pinterest or TikTok or Spotify or Slack or – well, that can be done, too, but only by undertaking separate development projects requiring additional time and money. 

A problem without any good solutions? It used to be. But now the Identity Cloud has a very good solution to the problem: custom providers.

Custom providers enable you to create your own social login providers, and without having to rely on ​Akamai​ support services. For example, would you like to allow users to log on to your website by using a Dropbox account? That’s fine: because Dropbox uses the Security Assertion Markup Language (SAML) you can make a few simple API calls and, in turn, connect your Identity Cloud website to Dropbox. (And, again, with no need for ​Akamai​ involvement, and at no cost to you.). The same thing is true for pretty much any social login identity provider (IdP) that uses one of the following authentication protocols:

• SAML 2
• OpenID Connect
• OAuth 2.0

Do you have preferred social login IdP that uses one of those authentication protocols? Then create a custom provider and use that IdP for social logins. Do you have a partner or a subsidiary or a contractor that uses one of those authentication protocols? Then create a custom provider and use that partner or subsidiary for social logins. The ball is now entirely in your court.

How custom providers work

There’s really nothing special about custom providers: they follow the same process used by standard, predefined IdPs such as Facebook or Twitter. The only real difference between a standard provider and a custom provider? It’s up to ​Akamai​ to create the standard providers, and to do so when it makes business sense for ​Akamai​ as well as for you. Bu comparison, you can create and deploy custom providers any time you want, without any ​Akamai​ involvement whatsoever. 

📘

Even better, you can often create and deploy those providers, from start to finish, in less than hour.

So what is the process used by both predefined IdPs and by custom providers? Let’s take a very high-level (and largely non-technical) look at the social login workflow:

1. An end user goes to your website, clicks a Login button, and is redirected to your Hosted Login login page. On the sign-in screen, the user clicks the button for your custom provider (e.g., Okta SAML):

   

2. The Identity Cloud loads the configuration file for your provider, a file that includes your attribute mappings. The attribute map copies user information from the social login identity provider to the user’s Identity Cloud user profile.

3. The user is redirected to the IdP’s website, where he or she logs on to that site using the same username and password they always use for the IdP. For example, if you click the Okta SAML button you’ll be redirected to the Okta login page and you’ll log on using your Okta username and password:

   

   Note that no special Identity Cloud credentials are required (which, of course, is the whole idea). In fact, while all Identity Cloud users must have an email address, users who register by using social login won’t have an Identity Cloud password. That means that they can only logon by using a social login IdP.

4. If authentication succeeds, the social login provider issues the user an authorization code and an access token; the user is then redirected back to the callback URI on your Identity Cloud-powered website or app. (You specify the callback URI at the time you configure social login for the custom identity provider.) There, the authorization code and access token issued by the IdP are exchanged for Hosted Login access, refresh, and identity tokens.

At that point the user is fully logged on to your site. 

And what if you’re using two-factor authentication (2FA)? That’s fine: 2FA follows the same process regardless of whether you log on by using traditional login (i.e., by providing an email address and password) or by using social login. If 2FA is called for then, after you’ve been authenticated by the IdP, you’ll need to go through two-factor authentication before Hosted Login will log you on.

📘

Something to keep in mind here: suppose your social login IdP also uses two-factor authentication. In that case, it's possible that a user will undergo 2FA when logging into the social login IdP and then have to go through 2FA when they're redirected back to Hosted Login. (One login, but two instances of two-factor authentication.) One way to minimize the number of times a user has to go through 2FA is to allow the use of trusted devices. With trusted devices, a user (as long they're using a trusted device) will usually be able to bypass 2FA on your Hosted Login site.

And once you are logged on, there’s no difference between a user who logged on with a username and password and a user who logged by using social login.