> For AI agents: [llms.txt](https://docs.trustedauth.com/llms.txt) provides a Markdown index of this documentation.

# Twitter

Using the provided template, you can integrate Twitter as an Identity Provider. When integrated, a user's Twitter account credentials and profile data can be used for single sign-on to your applications protected by IDaaS.

warning

Before you begin, you must have a Twitter account and an app configured for Twitter authentication. See <https://developer.twitter.com/en/docs/apps/overview>. Additionally, for users to use Twitter for authentication, they must already exist as users in IDaaS.

## Step 1: Copy the Redirect URI from IDaaS

1. In IDaaS, click Menu icon **>** **Security > Identity Providers**. The **Identity Providers List** page appears.
2. Click **Add** and select **Twitter** from the drop-down list. The **Add Identity Provider** page appears.
3. Enter a **Name** for your Identity Provider, for example, Twitter Login.
4. Locate the **Redirect URI** and copy it to a text file. You need this value in _Step 2: Add IDaaS to Twitter._
5. Keep this page open. You need it for _Step 4: Add Twitter as an Identity Provider in IDaaS_.

## Step 2: Add IDaaS to your Twitter app

1. Open another browser window and log in to your Twitter account.
2. In the browser bar, enter developer.twitter.com/portal. The **Dashboard** page appears.
3. Click **Projects and Apps** and then click the name of the app your want to integrate with IDaaS. The **App Details** page appears.
4. Scroll to **User Authentication Settings** and then click **Setup**. The **User authentication settings** page appears.
5. Toggle **OAuth 2.0** to On.
6. From the **Type of App** drop-down list, select **Web App**.
7. In the **Callback URI / Redirect URI** field, paste the Redirect URI you copied in _Step 1: Copy the Redirect URI from IDaaS_.
8. In the **Website URL** field, enter your IDaaS domain. For example: `<my_tenant>.us.trustedauth.com`.
9. Click **Save** to generate the **Client ID** and **Client Secret**.
10. Leave this page open or copy the **Client ID** and **Client Secret** to a text file. You need these values for _Step 3: Add Twitter as an Identity Provider in IDaaS._

## Step 3: Add Twitter as an Identity Provider in IDaaS

1. Return to the IDaaS browser window that you left open in _Step 1: Copy the Redirect URI from IDaaS_. 2. In the **Identity Provider** settings, do the following: 2. In the **Client ID** field, paste the **Client ID** from Twitter (see _Step 2: Add IDaaS to your Twitter app)._ 2. In the **Client Secret** field, paste the **Client Secret** from Twitter (see _Step 2: Add IDaaS to your Twitter app)._ 2. Enter the **Requested information from the Identity Provider**. 2. Enter the **Scopes**. OIDC sends scopes to the Identity Provider to retrieve information. This field is populated by default in the template.

   Associated with each scope are claims. The Identity Provider returns multiple claims based on the requested scopes. The openid scope is mandatory to do authentication or verification.

   2. Enter the **User Fields** to return user information fields from the Identity Provider. This field is populated by default in the template.

   3. Enter the **User Information Claims**. Separate each value with a space. Leave this setting blank to omit the feature.

      User information claims requests from the Identity Provider define specific claims that can also be requested for inclusion in the returned `id userinfo` response. This can be used in addition to the requested scopes.

   4. Enter the **Max Authentication Age** to set the allowed elapsed time, in seconds, since the last time a user was actively authenticated at the Identity Provider.

      For example, if you set a value of 300 seconds, if a user authenticated with the Identity Provider more than 300 seconds ago, they must re-authenticate. Leave this setting blank to omit this feature.

   5. Enter the **Auth Context Request Values** that are used by your Identity Provider. Separate each value with a space. Leave this setting blank to omit this feature.

   6. Enter the **Auth Method Request values** that are used by your Identity Provider. Separate each value with a space. Leave this setting blank to omit this feature.

2. Optional. Under **OIDC Endpoints**, select **Require User Info Signature** to require signature verification for responses to requests for user information.

3. Configure **Branding** as follows:

   1. Enter the **Login Button Text**. This is the text that appears on the IDaaS log in page.
   2. If your Identity Provider has a login button image, enter the URL in the **Login Button Image** field. The login button appears on the IDaaS log in page.

4. Configure **User Authentication** as follows:

   1. Select **Enabled for User Authentication**.

      During authentication, the Identity Provider returns a claim value that is used to find the IDaaS user based on a user attribute. The attribute mappings in the claim must uniquely identify the IDaaS user for mapping to be successful. If mapped successfully, the Identity Provider can be used as an alternative authentication method.

   2. In the **Domains** field, enter the domains returned from the OIDC Identity Provider after authentication. When set, any user ID ending with the domain (for example `user@mycompany.com`), or one of the domains is linked to the Identity Provider. Separate each domain with a space.

   3. From the drop-down list, select the **User Attribute used to identity the user** to map a claim returned from the Identity Provider to the IDaaS user (for example, `User ID/Alias`).

   4. Enter the **Claim used to identify the user**, (for example, `email`).

      > **Example:** If you set `User ID/Alias` as the user attribute, and you set `email` as the claim to use, the email address is then used to locate the user in IDaaS using the user's `User ID/Alias` value.

   5. Optional. Configure **System User Matching** and **Custom** **User Match Mapping**.

      - Every configured attribute must match the corresponding Identity Provider claim value and the IDaaS user attribute, which must both exist and match.
      - User matching is case-insensitive.

5. Optional (if user verification is used with the Identity Provider). Under **User Verification**, do the following:

   1. Select **Enable for User Verification** if you want the Identity Provider to be used for verification (for example, allowing an Open ID Connect Identity Provider to validate a user's photo or private identification information).
   2. Configure at least one **User Match Mapping**.
      - Users must already exist in IDaaS.
      - Every configured attribute must match both IDaaS and the Identity Provider.
      - User match attributes are case insensitive.

info
See [Manage policies, registration, and verification](/docs/people-and-access/manage-user-policies.md) for more information on the verification process.

6. Click **Save**.