Configure social login


What follows is information on the fastest and easiest way to enable social login in Hosted Login. However, there are other ways (and possibly better ways) to do this; it all depends on what you need to do and how you want things configured. See the article Configure social login in Hosted Login for more information.

Configuring Social Login

One of the many strengths of the ​Akamai​ Identity Cloud is its support for social login, the service that enables a user to log on to an app or website by using an account previously created on a social login identity provider such as Facebook, Twitter, or LinkedIn. With social login, users don’t need to use (and don’t need to remember) a separate username and password in order to access your site: as long as they can remember their Google username and password or their Sign in With Apple username and password then they’re good to go.

Obviously social login can be very useful, and very convenient, for your users. And yet, by default, Hosted Login doesn’t offer any options for logging on by using a Facebook account or a Twitter account. In fact, when you first fire up Hosted Login, you’re likely to be greeted by a sign-in screen that looks like this:


So does that mean that you can’t use social login with Hosted Login? No; it just means that you have to configure a few settings (and possibly create a social login app or two) before you can allow users to employ Google or Facebook or any other social login provider to sign in to Hosted Login.

To begin with, it’s important to know that Hosted Login relies, at least in part, on the Social Login Dashboard (formerly known as the Engage Dashboard). Before you can use social login, your application must be configured for social login. Is your application configured for social login? If you aren’t sure, one quick way to find out is to point your browser towards and log on. If you see the following message, you have not been enabled for social login:


For more information, and to enable social login, contact your Identity Cloud representative.

After you have access to the Social Login dashboard, you need to retrieve three pieces of information from that dashboard and then add that information to your Hosted Login application client. The information you need is found on the Settings page in the Social Login Dashboard:


Here’s what you need to do with that information:

  • Copy the domain name portion of your Application Domain and use it as the value for the rpx_realm setting in the application client. For example, if your application domain is then the domain name is greg-stemp.

  • Copy the App ID and use that as the value for the rpx_app_id setting in the application client.

  • Copy the API Key (Secret) and use that as the value for the rpx_key setting in the application client.

Those three client settings (rpx_realm, rpx_app_id, and rpx_key) must all be configured in your application client. In this document we won’t explain how to configure client settings; if you need a refresher on doing that, see Modify property settings or information on configuring client settings in Console.


By default, your application client should already include an application-level setting named rpx_server, and this setting should already have the value If for some reason you don’t have the rpx_server setting then you’ll need to add that setting as well.

After creating the required settings in the application client, your social login application and Hosted Login will be connected. All you have to do now is ensure that you have one or more social login providers configured in the Social Login Dashboard. Again, we won’t cover the ins and outs of configuring social login providers in this documentation; for instructions on how to set up a specific provider, see Social login configuration guides. For now, we’ll simply point out that, by default, the providers configured in the Social Login Dashboard (as well as the order in which they are configured) is exactly the same set of providers you’ll have available to you in Hosted Login. For example, suppose your Social Login Dashboard “widget” looks like this:


That means that, in Hosted Login, your users will have the option of using their Amazon or Facebook accounts to log on to your website or app:


Now, if a Hosted Login user clicks Facebook on your sign-in screen, they’ll be taken to the Facebook login page and then, after authenticating with Facebook, are redirected back to Hosted Login. If you were successfully authenticated, Hosted Login then issues you an access token, a refresh token, and an identity token, and sends you on your merry way.