Social Media Login 1.0

Social Media Login feature provides a form of single sign-on (SSO) that enables users to sign in to a secured website by using their existing social media account.

For example, you can configure the Social Login feature so that users can log in to your website with their Facebook or Twitter accounts instead of having to create an account specifically for your website. You can enable the Social Login feature for any social media platform that uses the OAuth 2.0 or OpenID Connect 1.0 standard for authorization.

Enabling this feature

To enable the Social Media Login 1.0 feature, add the following element declaration into your server.xml file, inside the featureManager element:

<feature>socialLogin-1.0</feature>

Examples

You can require that users log in with a specific social media provider, or you can give them a list of providers so that they can choose which they prefer to log in with. You can also restrict when they have certain log in options based on browser type, the application, and so on. The following examples show how to configure different scenarios in your server.xml.

Request log in with a social media ID

A customizable selection form is presented so the user can choose which provider they prefer to sign in with. The following example shows how to configure your application to request that the user logs in with their Google ID:

<googleLogin clientId="your_app_id" clientSecret="your_app_secret"  />

<!-- protected apps need to have a security constraint defined -->
<application type="war" id="formlogin" name="formlogin" location="${server.config.dir}/apps/formlogin.war">
    <application-bnd>
        <security-role name="Employee">
            <special-subject type="ALL_AUTHENTICATED_USERS" />
        </security-role>
    </application-bnd>
</application>

Provide a choice of social media providers to the user

You can provide the user with a choice of social media providers on a form from which they choose one to log in with. The following example presents the user with the choice of Google, GitHub, Facebook, LinkedIn, and Twitter with which to log in:

<googleLogin clientId="your_app_id" clientSecret="your_app_secret"  />
<githubLogin   clientid="your_app_id"          clientSecret="your_app_secret"  />
<facebookLogin clientId="your_app_id"          clientSecret="your_app_secret"  />
<linkedinLogin clientId="your_app_id"          clientSecret="your_app_secret"  />
<twitterLogin  consumerKey="your_app_id"       consumerSecret="your_app_secret"/>

<!-- protected apps need to have a security constraint defined -->
<application type="war" id="formlogin" name="formlogin" location="${server.config.dir}/apps/formlogin.war">
    <application-bnd>
        <security-role name="Employee">
            <special-subject type="ALL_AUTHENTICATED_USERS" />
        </security-role>
    </application-bnd>
</application>

Request log in with a social media ID only if the users is also in another registry

You can restrict the presentation of a social media provider to only users who are also in another configured registry. For example, use the mapToUserRegistry attribute to configure your app so that only users in the company LDAP registry can log in with their Google ID:

 <googleLogin  mapToUserRegistry="true" clientId="your app id"  clientSecret="your app secret"   />

 <ldapRegistry ...> ... </ldapRegistry>

For more information on configuring an LDAP registry, see the LDAP User Registry (ldapRegistry) feature.

Request log in with a social media ID or with their account for the configured registry

You can give users the option of logging in with either a social media provider or with their account on the configured registry. For example, use the enableLocalAuthentication attribute to configure your app so that users can have the option of logging in with a Google ID or with their account on their company’s LDAP registry:

<!-- user will be presented choice menu of either Google or ldap -->
<googleLogin  clientId="your app id"  clientSecret="your app secret" />

<socialLoginWebapp enableLocalAuthentication="true">

<ldapRegistry id="ldap" ...> ... </ldapRegistry>

Request log in with a social media ID for only a subset of applications, URLs, browsers, or IP addresses

To protect only a subset of applications, URLs, or IP addresses, use an authentication filter. The security configuration takes effect only when the conditions in the filter are met. For example, you might want a web app to be secured with the Social Media Login feature and a microservice app to be secured with the MicroProfile JWT (mp-jwt) feature:

<!-- only requests with "/mywebapp" in them will be authenticated using Google. -->
<googleLogin  authFilterRef="authFilter1" clientId="your app id"  clientSecret="your app secret" />

<authFilter id="authFilter1">
    <requestUrl
        id="myUrlFilter"
        urlPattern="/mywebapp"
        matchType="contains" />
</authFilter>

For more information, see authFilter.

Provide other social media logins as options to the user

To authenticate with a social media provider that is not configured out-of-the-box with Open Liberty, use a oauth2Login (for OAuth providers) or oidcLogin (for OpenID Connect providers) element. These elements supply the configuration details needed to work with the provider. These details can usually be obtained from the social media provider’s developer instructions. Here is an example for Instagram:

<oauth2Login id="instagramLogin" clientId="client_id" clientSecret="client_secret"
    scope="basic public_content"   responseType="code"
    tokenEndpointAuthMethod="client_secret_post"
    authorizationEndpoint="https://api.instagram.com/oauth/authorize"
    tokenEndpoint="https://api.instagram.com/oauth/access_token"
    userApi="https://api.instagram.com/v1/users/self"
    userNameAttribute="username"
    website="https://www.instagram.com/developer/authentication/">
</oauth2Login>

Liberty API packages provided by this feature

  • com.ibm.websphere.security.social

Features that this feature enables

Supported Java versions

  • JavaSE-1.7

  • JavaSE-1.8

  • JavaSE-11.0

  • JavaSE-14.0

Developing a feature that depends on this feature

If you are developing a feature that depends on this feature, include the following item in the Subsystem-Content header in your feature manifest file.

com.ibm.websphere.appserver.socialLogin-1.0; type="osgi.subsystem.feature"