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

# Integrate a generic OIDC and OAuth Web application

You can configure access to custom OpenID Connect (OIDC) applications by integrating a generic OIDC Web application on IDaaS. A Web application is a client application that can communicate securely with IDaaS using a client secret in order to obtain various tokens.

Before you begin, complete the following:

- Identify the attributes that IDaaS must contain to establish a connection between IDaaS and the OIDC application.
- Configure the account settings of your application to accept authentication attempts from your IDaaS account.

## Add a generic OIDC and OAuth Web application

Complete the following steps:

- [Step 1: Configure the General settings](#step-1-configure-the-general-settings)
- [Step 2: Configure claims](#step-2-configure-claims)
- [Step 3: Configure customizations](#step-3-configure-customizations)
- [Step 4: Configure a resource rule](#step-4-configure-a-resource-rule)
- [Step 5: Optionally, add a resource server](#step-5-optionally-add-a-resource-server)

### Step 1: Configure the General settings

1. Log in to an IDaaS account with a role assigned that allows you to configure applications on IDaaS.

2. Click Menu icon **>** **Security > Applications**. The **Applications List** page appears.

3. Click **Add**. The **Select an Application Template** page appears.

4. Do one of the following:

   - Select **OpenID Connect and OAuth Cloud Integrations** from the search drop-down list and scroll to find the application you want to add to IDaaS.
   - In the **Search bar**, enter a search option to filter for the application you want to add to IDaaS.

5. Click **Generic Web Application**. The **Add Generic Web Application** page appears.

6. Configure the following **App Settings**:

   1. Enter the **Application Name**.
   2. Enter the **Application** **Description.**

7. Configure the **OIDC Settings**.

   1. The **Client ID** is generated when you create the application on IDaaS. You cannot modify the Client ID.

   2. Select the **Client Authentication Method** from the drop-down list. When using the token, PAR, or revocation endpoints, clients use this authentication method to authenticate to the Authorization Server.

      1. If you select one of **Client Secret Basic**, **Client Secret Post**, or **Client Secret JWT** as the **Client Authentication Method**, complete the following:

         - Copy (or update and copy) the **Client Secret** value. You can then paste the **Client Secret** value into the required field of your client OIDC application account settings.
         - Optional. Set and copy the **Client Secret (Alternative)** value as an alternative option to support client secret rollover. You can then paste the **Client Secret (Alternative)** value into the required field of your client OIDC application account settings.

      note
      You can define your own Client Secret values. However, Entrust recommends that you use the strong secret value provided. You can also optionally view or regenerate a new client secret.

      2. If you select **Private Key JWT** as the **Client Authentication Method**, complete the following:

         - Select the **Supported Client Authentication Signing Algorithms** to specify the allowed signing algorithms.

      note
      When you select **Private Key JWT**, the client secret is not used for client authentication and is removed. Instead, the client uses a private key to sign a JWT assertion that is sent to the endpoints for authentication.

   3. Select **JWKS URI** or **JWK/JWKS JSON** to provide the JSON Web Key Set (JWKS) information for the application.

      - If you select **JWKS URI**, enter the URI where IDaaS can retrieve the JWKS information.
      - If you select **JWK/JWKS JSON**, enter the JWK or JWKS JSON information directly into the text box and optionally click **Pretty Print** to tidy the formatting.

   note
   The JWKS information is used when **JAR** (JWT Secured Authorization Request) is required or when **Private Key JWT** client authentication is selected. This information is needed for IDaaS to retrieve the public key information to verify the JWT assertion sent by the client.

   4. Set **Supported JWT Secured Authorization Request (JAR) Signing Algorithms** to specify the allowed signing algorithms when JAR is required.

   5. Set **Pushed Authorization Requests (PAR)** to define whether PAR requests are optionally supported or required by clients.

      - If you select **Optional** or **Required**, use **Pushed Authorization Requests (PAR) Format** to specify whether PAR is supported:
        - Only HTTP Post Parameters
        - A JWT Secure Authorization Request (JAR) request
        - Both

   6. Optional. Enter the **Reauthentication Time (Max Authentication Age)** to set the maximum amount of time that can elapse before a user is required to reauthenticate during a new login attempt. Leave this field blank to disable this feature.

   7. Select the **OIDC Signing Certificate** used to connect to the Service Provider.

   8. From the **ID Token Signing Algorithm** drop-down list, select the signing algorithm that is used to sign the ID tokens during authentication.

   9. From the **Userinfo Signing Algorithm** drop-down list, select the signing algorithm used to sign the user info data during authentication.

   10. From the **Access Token Signing Algorithm** drop-down list, select the signing algorithm that is used to sign the access tokens used with Resource Server APIs during authentication.

   11. Click **Add** to add a **Login** **Redirect URI**.

       The URI is the location a user is redirected to after being provided or denied access to the application. The value can be a URL, and you can add more than one value.

   note
   The login redirect URI hostname is added as a valid CORS origin for OIDC processing.

   12. Click **Add** to add a **Logout** **Redirect URI**.

       The URI is the location a user is redirected to after being logged out from a client application. The value can be a URL, and you can add more than one value. To redirect users back to the client application, the logout call by the client application must include the following parameters:

       - The `client_id` value (or alternatively `id_token_hint` value that identifies the client id in the `aud` claim of the supplied `id_token`).
       - The `post_logout_redirect_uri` value (or `redirect_uri` value) that is configured as one of the Logout Redirect URIs.

   13. Select the **Supported Grant Types** that your application uses to access OIDC authentication through IDaaS. The grant type tells IDaaS what flow to use to return authentication/authorization responses and grant request responses. You can select more than one grant type.

       **Supported Grant Types** include:

       - **Authorization Code.** Tokens obtained by the client application from the IDaaS OpenID Provider are passed by reference. The client application communicates directly with IDaaS to obtain these tokens. The supported response type is `code`.
       - **Implicit.** Tokens obtained by the client application from the IDaaS OpenID Provider are passed by value. The tokens are sent back directly to the application as part of the response to the authorization request. Supported request types are `id_token` and `id_token token`.
       - **None (OIDC No Flow).** This is typically used for OIDC test purposes. No OIDC tokens are sent back as part of the authorization request response.
       - **JWT IDaaS.** An authentication API-based grant type to obtain ID, Access, and Refresh Tokens. API calls are used to acquire these tokens.
       - **Client Credentials.** A client credentials grant request is used to obtain a server-to-server access token that can be used with Resource Server APIs.
       - **Refresh Token.** A refresh token grant request is used to obtain a new access token by using a valid refresh token.

   14. From the **Authorization Code PKCE Code Challenge** drop-down list, select the Proof Key for Code Exchange (PKCE) code challenge that must be used by clients to authenticate to the Authorization Server when an **Authorization Code** grant type is used.

   15. From the drop-down list, select the **Subject ID Attribute** that corresponds with the user attribute.

       - The **Subject ID Attribute** can be the **user name** or the **Federation ID** listed in the application account details on the OIDC application.
       - This attribute links IDaaS to the client OIDC application account.

   16. Optional. Select **Required Consent** to prompt users for consent during authentication.

   17. Optional. Enter a **Custom Consent Message** to include a message to users when consent is requested.

8. Select the **Supported Scopes**.

   A scope is a group of claims required for a connection between IDaaS and the OIDC application. Scopes are requested by the client during an authorization request. You can select more than one scope.

   - Your unique identifier (selected by default). If disabled, the OIDC application is strictly using an access token that can be used to access a resource server API on behalf of a user.
   - Address
   - Email address
   - Telephone number
   - Profile information

note
Click the arrow next to each scope to see the list of **Implied Claims** included in the scope. The list of **Implied Claims** is defined by OpenID Connect and cannot be modified.

Every Implied Claim included in the scopes you select under **Supported Scopes** should have an associated IDaaS user attribute so that the attribute is returned as part of the OIDC tokens sent back to the client. For example, if you select Address as a Supported Scope, then you must define an IDaaS user attribute for each **Implied Claim** associated with Address. See [Add a user attribute](/docs/people-and-access/manage-members/create-and-manage-user-attributes.md).

9. Click **Show Advanced Settings** to configure advanced settings.

   1. Select **Enable Organizations and Domain-Based Identity Providers** to allow organization information to be returned in OIDC claim values when users log in. When enabled, if users are associated with more than one organization and an organization has not been requested, users can select their organizations after they authenticate to their application.

   note
   When organizations are enabled, the corresponding OIDC claims must also be configured.

   2. Enter the **Default Resource/Audience Request Value** to include this value as the resource or audience parameter for every authorization request.

   3. Select **Include Authentication Time with all ID tokens** to include the authentication time with all tokens.

   4. Set the **ID Token Timeout** to the time (in minutes) that the ID token is valid before it expires.

   5. Set the **Userinfo Access Token Timeout** to the time (in minutes) that the access token is valid before it expires.

   6. If the refresh token grant type is selected to allow refresh token requests for OAuth access tokens, complete the following:

      1. Set the **Userinfo Endpoint Refresh Token Timeout** to the time that the refresh token associated with the access token is valid. This controls how long the specific refresh token can be used to acquire a new access token and refresh token.
      2. Set the **Userinfo Endpoint Refresh Token Limit** to the maximum amount of time the refresh token process is valid. This setting determines how long the refresh token exchange process can be used to obtain new access and refresh tokens.

   7. Set **Userinfo Sender Constraint** to define how userinfo access tokens are bound to clients. If you select DPoP (Demonstrating Proof of Possession), complete the following:

      1. Set **Userinfo DPoP Required** to require a DPoP proof for all requests.
      2. Set **Userinfo Supported DPoP Signing Algorithms** to specify the allowed signing algorithms.

10. Click **Save**.

note

After configuring the **General** settings, **Claims**, **Customization**, and **Resource Rules** tabs appear.

11. Proceed to _Step 2: Configure claims_.

### Step 2: Configure claims

1. Click the **Claims** tab. The **Claims** page appears.

   If required, add **Supported Claims** to map OIDC claims to IDaaS user attributes and related user information.

   - The supported claims define the claims that the client requests during an authorization request or claims that are returned automatically by IDaaS.
   - A claim value can be derived based on a user attribute, for example, `<FirstName>`.
   - A claim value can also be derived based on a user related attribute, for example, `[Groups]`.
   - The required claims depend on the OIDC application that you are configuring IDaaS.

   The default claims are

   - email
   - family_name
   - given_name
   - name
   - phone_number

   You can group claims, for example, the default claim, name, includes the user attribute `First Name`, a text-based value of a space and the user attribute value of `Last Name` so that the claim returned to the client is First Name `<space>` Last Name, for example `Alice Gray`.

2. To add a claim:

   1. Ensure that you have already created the required User Attributes in IDaaS (see [Create and manage user attributes](/docs/people-and-access/manage-members/create-and-manage-user-attributes.md)).

   2. Click Circle Plus icon. The **Add Claim** dialog box appears.

   3. In the **Claim Name** field, do one of the following:

      1. Select the **Claim Name** from the drop-down list.
      2. Type a **Claim Name** to create a new custom claim.

   4. In the **Enter the Claim value expected by the Service Provider** field, enter the following, as required:

      1. **User Attribute Value.** An IDaaS user attribute (see [Create and manage user attributes](/docs/people-and-access/manage-members/create-and-manage-user-attributes.md)).
      2. **Text-Based Value.** A text-based value. For example, to add a space between two claims or add text information.
      3. **Related Value.** Include user group or authenticator attributes. See [Configure OIDC claim to include user authenticators or groups](/docs/applications-and-sso/manage-applications/integrate-oidc-and-oauth-cloud-applications/configure-an-oidc-and-oauth-claim.md).

      > Example: `some text <first Name> <Last Name> [Groups]`

   5. Select **Always Return with User Info** to always return the user information with the claim.

   6. Select **Always Return with ID Token** to always return the ID Token with the claim.

   7. Click **Add**.

   note
   If required, click Pencil icon next to the claim and make the required changes. Click Trash icon to delete a claim.

3. Click **Save**.

4. Proceed to _Step 3: Configure customizations_.

### Step 3: Configure customizations

1. Click the **Customization** tab. The **Customization** page appears.
2. Deselect **Enable Go Back Button** if you do not want users to be able to go back to the application login page to log in.
3. Optional: Select **Respond Immediately for Unsuccessful Responses** to return to the application immediately after a login failure, rather than allow user to try again with a different userID.
4. Optional: Deselect **Show Login Redirect URL in My Profile** to hide the application from a user's profile.
5. Optional. Add a custom application logo, as follows:
   1. Click Circle Plus icon next to **Application Logo**. The Upload Logo dialog box appears.
   2. Click Arrow Up From Line icon to select an image file to upload.
   3. Browse to select your file and click **Open**. The **Upload Logo** **dialog box** displays your selected image.
   4. If required, resize your image.
   5. Click **OK**.
6. Select the **Login Options** that appear to users during login. You must select at least one. For details on each login option and requirements, see [Manage login options](/docs/applications-and-sso/manage-applications/manage-login-options.md).
7. Click **Save**.
8. Proceed to _Step 4: Configure a resource rule._

### Step 4: Configure a resource rule

1. Click the **Resource Rules** tab.
2. Click **Add Resource Rule**.
3. Follow the instructions in [Create and manage resource rules](/docs/authentication-and-security/create-and-manage-resource-rules/create-resource-rules.md).

### Step 5: Optionally, add a resource server

1. Click the **Resource Servers** tab.
2. Click **Add Resource Server**.
3. Follow the instructions in [Add an API/URL resource server](/docs/applications-and-sso/manage-applications/integrate-oidc-and-oauth-cloud-applications/manage-resource-servers/add-an-api-url-resource-server.md).