> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ulm.m1amdocs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Associate Social Account to User Process

Also known as simply Associate Social Process, it enables an authenticated user to link their existing Digital Identity Management User ID with a social account of their choice.

This Process implements the [OAuth 2.0 authorization protocol](https://datatracker.ietf.org/doc/html/rfc6749) for the transferring of resources between separate parties. Digital Identity Management follows this protocol to retrieve user details from the social account provider to create and store the association in Digital Identity Management. Once the association is established, the user will be able to authenticate into Digital Identity Management (i.e., into your organization's Digital Identity Management-powered client application) using the social account.

## Adding the Provider ID in the initial Request

Like most Processes, this Process is initialized by the Process Start API. The Process Start API optionally consumes no payload but you can actually add the required parameters upfront in the initial API request URL.

For example, in a normal invocation, the Process Start API consumes no payload:

```
**POST https://\{your.url\}/process/start/socialFederation.AssociateSocialMedia.v1.0**
<no body>
```

Digital Identity Management then responds with a request for request for a supported `providerID`:

```
**RESPONSE - body**
{
   "processId": "8f41d5cc-a4ab-45e9-9e3b-7f58a2ed183f",
   "processName": "socialFederation.AssociateSocialMedia.v1.0",
   "displayMessage": "Please input required information",
   "parameters": {
      "providerId": "String"
   },
   "stepName": "ProviderPrompt",
   "lastStep": false,
   "output": {
      "providers": [
         "linkedin",
         "google",
         "facebook",
         "apple"
      ]
   }
}
```

The response includes an array of provider options. Note that this array will only include options that are configured and enabled. In other words, if your organization only has Facebook and Google enabled in the Amdocs Subscription Marketplace Admin web app, then only those options should appear in this scenario.

The client would then need to display the list of available providers to the end user, and pass the user selection back to Digital Identity Management in a subsequent Process Step API, such as [PUT /process/step](c_processStep) :

```
**PUT https://\{your.url\}/process/step**
{
    "processId": "8f41d5cc-a4ab-45e9-9e3b-7f58a2ed183f",
    "parameters": {
        "providerId": "facebook"
}
```

In response, the Process would pass along its redirectURL to the client, and flow continues as normal.

**However**, the Associate Social Process is one of the exceptions where the client application can also invoke the Process with the specified `providerId` in the initial Process Start request.

The client specify the `providerID` in either the request:

```
**POST https://\{your.url\}/process/start/socialFederation.SocialMediaAssistedOnboarding.v1.0?providerId=facebook**
<no body>
```

Alternatively, the client can specify the provider ID in the request body instead:

```
**POST https://\{your.url\}/process/start/socialFederation.SocialMediaAssistedOnboarding.v1.0**
{
   "parameters": {
      "providerId": "facebook"
}
```

Regardless of which method your prefer, this effectively skips that initial step that requires an explicit selection. As a best practice, adding the `providerID` to the request URL or request body enables you to build your application to display clear badges or links for the user (e.g., "Link Facebook to User Profile"). The client can then invoke the provider-specific variation of the Process when a user clicks on a provider-specific badge or link.

## Process Flow

This flow describes the Associate Social Process at a high level, "happy path" flow:

**Preconditions**

* The Digital Identity Management User is fully activated with at least one verified email or mobile.
* The user is currently authenticated and in the client's version of the user profile or user settings menu.
* The user has at least one social media account with a supported provider.
* The social provider integration has been enabled and configured in the MarketONE Admin console.

**Basic Flow**

1. The user selects to add a specific social media account to their sign-in options.
2. The client redirects to the social provider, and the user authenticates into that provider.
3. The social provider navigates the browser back to Digital Identity Management.
   * On the backend, the provider sends along an authorization grant code to Digital Identity Management.
   * Digital Identity Management makes a separate call to the provider backend and exchanges the code for an access token.
   * Digital Identity Management makes another call to the provider backend to redeem the token for user data.
   * The user data includes the user's name, email/mobile, and an internal social media ID from the provider.
4. Digital Identity Management searches for any existing User entity currently associated to this particular social media ID.
5. If no User entity is found, the Process prompts the user to confirm that they want to connect their User ID to the selected social media account.
6. The user confirms and Digital Identity Management associates the social media with the User ID.

**Postconditions**

* The user's social account is associated to their Digital Identity Management User ID.
* The social account can be used for authentication with the [Onboard and Authenticate User with Social Account Process](c_onboardAuthenticateUserSocial).

**Possible or Common Errors**

* The user failed to sign-in with the social provider's website.
* The social media account is already associated to another Digital Identity Management User ID.
* The selected social media provider is not enabled or supported.
* Access token error (social provider does not return user information to Digital Identity Management).

## App Settings

This Process currently has no relevant app settings to configure the Process behavior.

## User Journey Diagram

This flow diagram illustrates the standard user journey using the **Associate Social Account to User ID** Process.

\[product: dim]<img src="https://mintcdn.com/amdocs-ulm/XSI-_zBHRIt1HJAz/portal/m1Connect/processGuide/images/m1c_userJourneyAssociateSocial.png?fit=max&auto=format&n=XSI-_zBHRIt1HJAz&q=85&s=a72632ef9553319b7619796dc15b6b3b" alt="" width="2266" height="2840" data-path="portal/m1Connect/processGuide/images/m1c_userJourneyAssociateSocial.png" />\[/product: dim]

## Use Cases

See the following use case topics for guided API walk-throughs of this Process:

* [Associate social account to existing Digital Identity Management User](c_associateSocial)
* [Social association errors](c_socialErrors)

## See Also

* Once the user associates a social account to their User ID, then can then authenticate into Digital Identity Management with the [Onboard & Authenticate User with Social Account](c_onboardAuthenticateUserSocial) Process.

* The same Process,[Onboard & Authenticate User with Social Account](c_onboardAuthenticateUserSocial) onboards a user into Digital Identity Management for the first time.

* The [Dissociate Social Account from User](c_dissociateSocialAccount) Process removes a currently associated account.

* **[Associate social account to existing User](../topics/c_useCaseAssociateSocial)**

* **[Social account association errors](../topics/c_associateSocialErrors)**

**Parent topic:**[Identity Management Processes](../images/c_identityProcesses)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.