# OpenID Connect (OIDC) Integration Follow the steps documented below to integrate your Org with an OIDC-compliant Identity Provider (IdP) such as Okta for Single Sign On (SSO). **Important** Only users with "Organization Admin" privileges can configure SSO in the Web Console. --- ## Step 1: Create IdP in Web Console - Log in to the **Web Console** as an **Organization Admin**. - Navigate to **System β†’ Identity Providers**. - Click **New Identity Provider**. - In the **IdP Configuration** tab, provide a **unique name** for the Identity Provider. - Optionally, enter a **description** for reference. - Select **OIDC** as the **Authentication Type**. - Choose **Okta** as the **Provider Name**. - Enter the **Domain** associated with the organization (for example, `mycompany.com`). - Provide an **Admin Email ID** (for example, `admin@mycompany.com`). **Important** - Within an organization, both the **IdP Name** and **Domain** must be unique. A domain used in one organization can be reused in a different organization. - The **Domain** and **Admin Email’s domain** must match. For example, if the domain is `mycompany.com`, the admin email must belong to the same domain (for example, `admin@mycompany.com`). At this point, the configuration cannot be saved or continued further. The remaining fields: **Client ID**, **Client Secret**, **OP Domain URL**, and **Group Attribute Name** must be populated after configuring the corresponding Okta application and retrieving these details from Okta. Once these values are available, return to this page, complete the remaining fields, and then proceed with the setup. --- ## Step 2: Configure OIDC App in Okta - Login into your **Okta** Org as an **Administrator**. - Navigate to **Applications β†’ Applications** and click **Create App Integration**. - Select **Sign-in method: OIDC – OpenID Connect**. - Select **Application type: Web Application** and click **Next**. - Provide an **App Integration Name**. - Select **Authorization Code** as the grant type. - For **Sign-in redirect URIs**, enter a placeholder (this will be updated later from Web Console). - Make the required **Assignments** and disable the **Federation Broker Mode**. - Click **Save**. --- ## Step 3: Capture Client Credentials - Copy the **Client ID**, **Client Secret**, and OP Domain URL from the below page. - Enable **PKCE** if required. - Paste these values into the Console configuration page. - Provide the **Group Attribute Name** and save the IdP configuration. > 🚨 **Important:** Ensure that the **OP Domain URL** includes the protocol prefix β€” `http://` or `https://` β€” to make it a valid URL. The process cannot proceed without a properly formatted URL. - Copy the **Redirect URL** generated by the web console to update it in Okta. - Paste the URL under **General Settings β†’ Login β†’ Sign-in redirect URIs** as shown below and click **Save**. Once saved, the OIDC app is configured in OKTA. --- ## Step 4: Webhook Configuration (Optional) In the Web Console, configure the webhook if required, and click **Save & Exit**. Once the configuration is complete, a verification email is sent to the admin email ID specified on the IdP Configuration page. The verification must be completed to enable SSO login using the configured OIDC app. --- ## Step 5: Configure Group Claims in Okta - Navigate to **Security β†’ API**. - Select **Default** and click on the **Claims** tab. - Click **Add Claim**. - Provide the claim details as shown in the screenshot below. **Important** The **Claim Name** must exactly match the `Group Attribute` configured in the Web Console. - Click **Create**. After configuring, the **groups** claim appears under the **Claims** tab in the authorization server. The **groups** claim maps the user’s group memberships using a regular expression defined in the **Value** field. This ensures that only the matching groups are passed in the ID token during authentication. Make sure the **Claim Name** for `groups` matches the name specified in the OIDC configuration at the time of creation or update. --- ## Step 6: Configuring Access Policies Access policies define the rules and conditions that determine how users can access an OIDC application. These policies help control authentication behavior and client-level access. ### Navigate to Access Policy Settings 1. In the **Okta Admin Console**, go to **Security β†’ API**. 2. Click on the **default** authorization server to open its configuration. ### Create a New Access Policy 1. Select the **default** authorization server. 2. Click on the **Access Policies** tab and then select **Add Policy**. 3. In the **Add Policy** dialog: - Enter a **Policy Name** and a **Description**. - Under **Assign to**, choose one of the following: - **All clients** to apply the policy globally. - **The following clients** to restrict the policy to specific OIDC apps by selecting the app name. 4. Click **Create Policy** to save the configuration. --- ## Step 7: Add a rule to the policy Once the policy is created, click **Add Rule**. Enter the details to define the grant type, user assignments, scopes, and token lifetimes. Once all required fields are configured, click **Create rule** to add the rule to the policy. > **Note**: On successful configuration, create a user and assign the user to the appropriate group in the IdP application. --- ## Troubleshooting ### Scenario 1: User Not Assigned to OIDC Application **Description:** The IdP is configured and verified in the Web Console. The OIDC app is created and configured in Okta, but the user is created without being assigned to the OIDC application. **Error Message:** **Resolution:** - Assign the user to the correct OIDC client application in Okta. - If the same error appears even after assignment, verify that the user is assigned to the right client application. ### Scenario 2: Access Policy Not Configured **Description:** The user is assigned to the OIDC application, but no access policy or rule is configured in Okta. **Error Message:** **Resolution:** - Create and configure the required access policy and rule for the application in Okta. - Once configured, the error is resolved.