Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-6222

Social Provider Authentication with OAuth Consent to enable user registration and login


    • Type: Retrospective
    • Status: Closed
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: OpenIDM 5.0.0
    • Component/s: _Feature Requests
    • Labels:


      Business Problem:
      Social registration (sign-on) and login allow the enterprise users to use social providers such as Google, Facebook or LinkedIn to register first and then use that identity to authenticate. Social sign-on and login offers consumers the ability to register and log in on websites and apps with a social network profile. It simplifies the login experience by integrating social login credentials as a customer touch point and makes the user registration process easy.

      Customer Value:
      1. Create a 360 view of the customer base and its users.
      2. Social Sign-on and Login offers a variety of benefits:
      • Increase conversion rate as users uses existing Social Network logins (in a few clicks) rather than filling out long registration pages.
      • Opportunity for greater engagement as users can quickly identify which one of their friends has also visited that same website and interact with them.
      • More accurate contextual information as first-time users information can be used to match relevant content, media, products, and even advertisements.
      • Reduced time in marketing/sales funnels as prospects quickly can be served up relevant products and even shopping carts of peer recommended products within seconds.

      Benefits for OpenIDM:
      1. Captures the following user data from the social providers once they establish an identity in OpenIDM
      • Identity data like First Name, Last Name, Email, Birthday, Gender, Location, Likes and Interests, Relationship, Education
      • System data like location, IP address, Time zone,
      • Behavioral data like purchases, ad clicks, page views, shares, comments, reviews
      2. Ability to trigger social profile syncs automatically for the users even if the user has not logged in after first-time consent and keep the customer data up to date
      3. Continue to do progressive profiling of the users and gather rich data around users.

      1. Mike is an administrator for OpenIDM; Wendy is the end user, and Sam is the developer.
      2. Mike as an admin can successfully log in and be able to configure the social providers that Wendy is allowed to register in OpenIDM
      3. Mike is allowed to either select a set of scopes that is available by default or configure the scopes for the Social providers that define the attributes and the meta data to gather for all users per social provider.
      4. Wendy is allowed to provide consent for each of the social provider scopes before the data is captured from the social providers.
      5. Wendy is allowed to log in and authenticate through FB, Google, and LinkedIn for OAuth based apps and resources including OpenIDM

      Main Flow

      Persona Mike:
      1. Mike goes to the OpenIDM admin login page
      2. Mike enters username and password
      3. Mike is authenticated and logs into OpenIDM
      4. Mike goes to the social provider configure tab and selects the providers to enable the users
      5. Mike configures the scopes for each of the social providers
      6. Mike saves the configuration.

      Persona Wendy:
      1. Wendy clicks on FB, Google or LinkedIn since she has been enabled by Mike
      2. If Wendy has not yet registered through the social provider, force Wendy to authenticate through the Social provider first.
      3. If credentials were valid and successfully authenticated to the social provider, based on the scope configured to present the consent form for Wendy to approve.
      4. If Wendy approves,
      5. If an identity does not exist in OpenIDM, gather her identity data and create a user in OpenIDM and enable the profile ID ( as registered) for the specific social provider
      6. If an identity does exist for the user in OpenIDM, do not create the user.
      7. Based on the scope set by Mike, gather all the system and the behavioral data from the social provider for Wendy and store in OpenIDM.

      Use Case 1: Wendy, a new user register via social account (provisioning scenario)
      • Wendy clicks on sign-up with Google, Facebook or LinkedIn
      • Let Wendy know that OpenIDM will capture the following from their social profile, their public profile details, email address, location, Time zone
      • SUCCESS response is sent
      • Wendy, a new user, is created, and the user’s data gets registered in user store with the corresponding profile id enabled for the Google, FB, and LinkedIn

      Use Case 2: Wendy, already registered through Google, now logs in through the social provider (authentication scenario where social email is the same as the email of an existing account in OpenIDM)
      • Wendy clicks on Login with Google
      • If OAuth Token exists for Google, Login Success
      • If OAuth token expired, re-authenticate Wendy to Google
      • SUCCESS response is sent, and the user data is synced into IDM if any changes
      • If Login Failure - Do nothing. Show failure with the exception

      Use Case 3: Wendy, already registered, tries to log in via a different social network (authentication scenario - social email is different from the one in user Store)
      • Wendy clicks on login with LinkedIn (has registered through Google)
      • If the email address for the both social network Google and LinkedIn in is different (i.e. profile ID for LinkedIn is not enabled yet), Wendy is prompted to use the social email with which he registered first. If login success, the new email address is stored under the account, Profile ID for LinkedIn is also enabled.
      • SUCCESS response is sent, and user data is synced if any changes

      Use Case 4: Wendy is registered and is enabled to sign-in through multiple Social providers and now wants to unlink from Google
      • Wendy logs into OpenIDM
      • Goes to configure-> System preference-> Social Providers
      • Select the Google to unlink, the profile ID for Google is now disabled
      • The Google icon on the login screen is not shown anymore for Wendy
      • The automatic sync for Wendy’s profile is also disabled.( Wendy’s data in OpenIDM not purged)

      Use Case 5: Wendy registered via Social but attempts a login to OpenIDM through email password (authentication scenario)
      • if Wendy’s email is registered and a profile ID for a social provider is enabled, but the password field is blank, force Wendy to log in using the appropriate social sign-in

      Post-conditions and Acceptance Criteria:
      1. Mike is allowed to configure the social providers in OpenIDM through admin UI and a REST call. When disabled, the social icon is not visible on the login page for the Wendy user. When enabled, the icon is visible, and Wendy will be allowed to register.
      2. Mike is allowed to set the scope for the configured social providers in OpenIDM through UI and a REST call
      3. Sam has all the developer documentation for new interfaces, scripts, and functions associated with Social Login and can be accessed from the UI (help) or directly within the appropriate FR Documentation (Integrators guide, samples, etc.).
      4. Sam cannot register to social providers through a REST call since the login to the social provider, and consent approval is all browser based.
      5. Wendy can register through FB, Google, and Linked
      6. If profile ID is set to enable for FB and Google, she can login/authenticate to social IdP protected apps and resources through OpenIDM.
      o OpenIDM acts as a client to generate the OAuth token from the social provider on behalf of Wendy and allows her to log into the protected app or the resources.
      o If an OAuth token has not expired for Wendy in OpenIDM, allow successful app/resource authentication else makes Wendy re-authenticate to the social provider to get a fresh OAuth token.
      o If OAuth token has expired for Sam during login and if he is interacting through the REST call then throw a “session timeout” since we cannot show the re-authentication window.


          Issue Links



              • Assignee:
                brmiller Brendan Miller
                kavya.muthanna Kavya Muthanna [X] (Inactive)
              • Votes:
                0 Vote for this issue
                5 Start watching this issue


                • Created: