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

# Set up an Okta connector

> C1 provides identity governance and just-in-time provisioning for Okta. Integrate your Okta instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access.

<Tip>
  **This is an updated and improved version of the Okta connector!** If you're setting up Okta with C1 for the first time, you're in the right place.
</Tip>

## Capabilities

| Resource                        | Sync                                                          | Provision                                                     | Delete                                                        |
| :------------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------ |
| Accounts                        | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |                                                               |
| Applications                    | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |                                                               |
| Groups                          | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Roles                           | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |                                                               |
| Standard and custom admin roles | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |                                                               |                                                               |
| Secrets - API tokens            | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |                                                               |                                                               |

<Note>
  The standard roles **Workflows Administrator**, **Access Certifications Administrator**, and **Access Requests Administrator** appear as Custom Roles in C1. Enable **Sync Custom Roles** to see them. The Okta API returns these roles through the same endpoint as custom roles.
</Note>

<Note>
  Synced groups expose their source type on the resource profile as **`type`**. Today, Okta defines three values:

  * **`OKTA_GROUP`** — a group created and managed natively in Okta.
  * **`APP_GROUP`** — a push group created when a SCIM-integrated app mirrors its groups into Okta.
  * **`BUILT_IN`** — a system group provided by Okta (these are also marked immutable).

  The connector surfaces whatever value Okta returns, so any future group types Okta introduces will appear here verbatim.

  Use this attribute in policies and access profiles to verify that bindings and grants reference the intended kind of group, especially when an Okta-native group and an app push group share the same name.
</Note>

The Okta connector supports [automatic account provisioning](/product/admin/account-provisioning).

This connector does not support account deprovisioning. You must deprovision accounts directly in Okta.

Syncing standard and custom admin roles requires a super admin token.

[This connector can sync secrets](/product/admin/inventory) and display them on the **Inventory** page.

### Connector actions

Connector actions are custom capabilities that extend C1 automations with app-specific operations. You can use connector actions in the [Perform connector action](/product/admin/automations-steps-reference#perform-connector-action) automation step.

| Action name   | Additional fields                                                                   | Description                                                                                                                                                                                             |
| ------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| enable\_user  | `user_id` (string, required)                                                        | Unsuspends a suspended Okta user account                                                                                                                                                                |
| disable\_user | `user_id` (string, required)                                                        | Suspends an active Okta user account                                                                                                                                                                    |
| create        | `name` (string, required), `description` (string), `userMembers` (resource ID list) | Creates a new Okta group with optional initial members                                                                                                                                                  |
| modify\_group | `group_id` (string, required), `name` (string), `description` (string)              | Updates the name and/or description of an existing Okta group. Returns success without calling the Okta API if the supplied values already match the group's current name and description (idempotent). |

<Note>
  Group deletion is available via the CLI using the `--delete-resource` flag. To delete a group, run:

  ```
  baton-okta --api-token $BATON_API_TOKEN --domain $BATON_DOMAIN --delete-resource "<okta-group-id>" --delete-resource-type "group"
  ```

  Use the raw Okta external ID (e.g. `00g1abc2def3GHI4jk5`), not the C1 resource ID. Group deletion is not available through the C1 UI or the Automations tab.
</Note>

## Authentication methods

The Okta connector supports two authentication methods:

| Method                    | Description                                        | Best for                                                               |
| :------------------------ | :------------------------------------------------- | :--------------------------------------------------------------------- |
| **API Token**             | Uses an Okta API token tied to an admin account    | Quick setup, broad access                                              |
| **OAuth 2.0 Private Key** | Uses an Okta OIDC app with client credentials flow | Least-privilege scopes, short-lived tokens, easier credential rotation |

The **OAuth 2.0 Private Key** method is recommended for production environments because it provides scoped access with short-lived tokens rather than a long-lived API token.

## Gather Okta credentials

Configuring the connector requires you to pass in credentials generated in Okta. Gather these credentials before you move on.

### API token permissions and C1 capabilities

C1's capabilities depend on the permissions of the API token used to set up the connector:

| C1 capability                    | Custom read-only token                                        | Read-only + app admin + group admin token                     | Super admin token                                             |
| :------------------------------- | :------------------------------------------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------ |
| Review group membership          | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Provision group membership       |                                                               | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Review application assignment    | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Provision application assignment |                                                               | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Review admin roles               | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |                                                               | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Create Okta group (action)       |                                                               | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Modify Okta group (action)       |                                                               | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Delete Okta group                |                                                               | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |

To learn more about Okta roles, visit [the Okta documentation on administrator roles and permissions](https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm).

<Tip>
  The **Custom Read-Only Admin Role** provides the minimum permissions required to read admin role assignments in Okta.
  This role is necessary when admin roles are assigned to Okta groups. Without it, the connector will fail during synchronization if it encounters a group that's assigned to an admin role, as it won't have permission to read the group's membership.
</Tip>

### (Optional) Create a custom read-only admin role

To give the C1 integration limited read-only admin permissions, create a custom Okta admin role and resource set and assign them to the admin you'll use to generate the API key.

<Steps>
  <Step>
    In Okta, log in to the Admin Dashboards and navigate to **Security** > **Administrators** > **Roles**.
  </Step>

  <Step>
    Click **Create new role**.
  </Step>

  <Step>
    Give the new role a name and description, such as "C1 integration read-only admin".
  </Step>

  <Step>
    Give the role the **View roles, resources, and admin assignments** permission (this is found in the **Identity and access management permissions** section).
  </Step>

  <Step>
    Click **Save role**.
  </Step>

  <Step>
    Next, navigate to **Security** > **Administrators** > **Resources**.
  </Step>

  <Step>
    Click **Create new resource set**.
  </Step>

  <Step>
    Give the new resource set a name and description, such as "Read-only admin for C1 integration".
  </Step>

  <Step>
    Click **Add resources**.
  </Step>

  <Step>
    Find the **Identity and access management** resource type and select **All Identity and Access Management resources**.
  </Step>

  <Step>
    Click **Save selection**, then click **Create**. The resource set is now shown on the **Resources** tab.
  </Step>

  <Step>
    Now we'll assign the resource set to an admin. (If you need to do so, make a service account following the instructions below, then return to finish this process.) Click **Edit** on the new resource set and select **View or edit assignments**.
  </Step>

  <Step>
    In the **Complete the assignment** section of the page, select the role and resource set you just created.
  </Step>

  <Step>
    Click **Save changes**.
  </Step>
</Steps>

Now you can skip ahead to the instructions to create an API token.

### (Optional) Create a service account for the API token

If desired, you can create a service account user in Okta that has the permissions for the API token.

<Steps>
  <Step>
    Navigate to **Directory > People** and click **Add person**.
  </Step>

  <Step>
    Enter the necessary user details to create a user. You might want to use identifiers that make it easily recognizable as a service account, such as First Name: ReadOnly, Last Name: ServiceUser.
  </Step>

  <Step>
    Set the **Password** for the account and carefully save it somewhere secure.
  </Step>

  <Step>
    Click **Save**.

    <Tip>
      At this point, if you've created a custom read-only role, stop here and return to the instructions above. If you're using a standard Okta admin role, continue on.
    </Tip>
  </Step>

  <Step>
    Navigate to **Security > Administrator** and click **Add administrator**.
  </Step>

  <Step>
    Enter the email address for your newly created Service Account to select the user.
  </Step>

  <Step>
    Select the administrator roles to grant: Super Administrator or a combination of Read Only + Application Admin + Group Admin.
  </Step>

  <Step>
    Click **Add Administrator**.
  </Step>
</Steps>

### Create an API token

We strongly recommend creating a dedicated token for the C1 integration so you can manage the token's lifespan and control per-token rate limits.

<Tip>
  When **creating** an API token, Okta assigns the permissions of the *currently logged-in user* to the token. If, for example, you wish to use a Read Only Admin-scoped API token, you must log in to Okta as a user with the Read Only Admin role assigned.
</Tip>

<Steps>
  <Step>
    Log into Okta with the account you'll use to generate the API token.

    The account must have **Super Administrator,** the custom read-only role you created above, or a combination of **Read Only/App Admin/Group Admin** privileges. The permissions on the API token affects what features and functionality are available from C1. Before you begin, review the chart in [API permissions and C1 capabilities](/baton/okta#api-token-permissions-and-conductorone-capabilities) to make sure you're creating a token with the right permissions for your needs.
  </Step>

  <Step>
    In the Okta console, navigate to **Security > API** and click **Tokens**.
  </Step>

  <Step>
    Click **Create Token**.
  </Step>

  <Step>
    Give your token a name, such as **C1**, and click **Create Token**.
  </Step>

  <Step>
    Copy and save the new API token.
  </Step>
</Steps>

**Done.** Next, move on to the connector configuration instructions.

### (Alternative) Set up an OAuth 2.0 OIDC app

Instead of an API token, you can use an OAuth 2.0 client credentials flow with a private key. This provides scoped, least-privilege access with short-lived tokens.

<Steps>
  <Step>
    In Okta, navigate to **Applications** > **Applications** and click **Create App Integration**.
  </Step>

  <Step>
    Select **API Services** and click **Next**.
  </Step>

  <Step>
    Give the app a name (e.g., "ConductorOne Integration") and click **Save**.
  </Step>

  <Step>
    On the app's **General** tab, note the **Client ID**.
  </Step>

  <Step>
    In the **Client Credentials** section, select **Public key / Private key** as the client authentication method.
  </Step>

  <Step>
    Click **Add Key**, then either generate a new key pair or paste your own public key. Save the private key securely — you'll need it when configuring the connector.
  </Step>

  <Step>
    Note the **Key ID** shown for your key.
  </Step>

  <Step>
    Navigate to the **Okta API Scopes** tab and grant the scopes required for your use case:

    * `okta.users.read` and `okta.groups.read` (required for sync)
    * `okta.roles.read` and `okta.apps.read` (required for sync)
    * `okta.users.manage`, `okta.groups.manage`, `okta.roles.manage`, `okta.apps.manage` (required for provisioning)
    * `okta.apiTokens.read` (required when **Sync secrets** is enabled)
  </Step>

  <Step>
    Navigate to the **Admin Roles** tab and assign an appropriate admin role to the app (e.g., **Super Administrator** or a custom role with the permissions you need).
  </Step>
</Steps>

You'll need the **Client ID**, **Private Key**, and **Private Key ID** when configuring the connector.

## Configure the Okta connector

<Warning>
  To complete this task, you'll need:

  * The **Connector Administrator** or **Super Administrator** role in C1
  * Access to the set of Okta credentials generated by following the instructions above
</Warning>

<Tabs>
  <Tab title="Cloud-hosted">
    **Follow these instructions to use a built-in, no-code connector hosted by C1.**

    <Steps>
      <Step>
        In C1, navigate to **Integrations** > **Connectors** and click **Add connector**.
      </Step>

      <Step>
        Search for **Okta v2** and click **Add**.
      </Step>

      <Step>
        Choose how to set up the new Okta connector:

        * Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren't yet managed with C1)

        * Add the connector to a managed app (select from the list of existing managed apps)

        * Create a new managed app
      </Step>

      <Step>
        Set the owner for this connector. You can manage the connector yourself, or choose someone else from the list of C1 users. Setting multiple owners is allowed.

        If you choose someone else, C1 will notify the new connector owner by email that their help is needed to complete the setup process.
      </Step>

      <Step>
        Click **Next**.
      </Step>

      <Step>
        Find the **Settings** area of the page and click **Edit**.
      </Step>

      <Step>
        Select your authentication method: **API Token** or **OAuth 2.0 Private Key**.
      </Step>

      <Step>
        Enter your Okta domain (the URL of your Okta instance is `<YOUR DOMAIN>.okta.com`) into the **Okta domain** field.
      </Step>

      <Step>
        Enter your credentials:

        * For **API Token**: paste your API token into the **API token** field.
        * For **OAuth 2.0 Private Key**: enter your **Okta Client ID**, **Okta Private Key ID**, and paste the **Okta Private Key** (PEM-encoded).
      </Step>

      <Step>
        **Optional.** If desired, click the checkbox to **Sync custom roles**.
      </Step>

      <Step>
        **Optional.** If desired, click the checkbox to **Skip secondary emails** when syncing user information.
      </Step>

      <Step>
        **Optional.** If desired, click the checkbox to **Skip app groups** to exclude Okta push groups (APP\_GROUP type) from sync. This is useful when push groups created by SCIM-integrated apps are not needed for access management workflows.
      </Step>

      <Step>
        **Optional.** If desired, click the checkbox to **Sync inactive apps** to include inactive (disabled) Okta applications in sync. By default, only active applications are synced.
      </Step>

      <Step>
        **Optional.** Enable **Sync secrets** to display them on the [Inventory page](/product/admin/inventory).
      </Step>

      <Step>
        **Optional.** Enter a list of user email domains that will be included in the connector's sync. If you do not specify any domains here, the connector will sync all available accounts regardless of email domain.
      </Step>

      <Step>
        Click **Save**.
      </Step>

      <Step>
        The connector's label changes to **Syncing**, followed by **Connected**. You can view the logs to ensure that information is syncing.
      </Step>
    </Steps>

    **Done.** Your Okta connector is now pulling access data into C1.
  </Tab>

  <Tab title="Self-hosted">
    **Follow these instructions to use the Okta connector, hosted and run in your own environment.**

    When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.

    ### Resources

    * [Official download center](https://dist.conductorone.com/ConductorOne/baton-okta): For stable binaries (Windows/Linux/macOS) and container images.

    * [GitHub repository](https://github.com/conductorone/baton-okta): Access the source code, report issues, or contribute to the project.

    ### Step 1: Set up a new Okta connector

    <Steps>
      <Step>
        In C1, navigate to **Integrations** > **Connectors** > **Add connector**.
      </Step>

      <Step>
        Search for **Baton** and click **Add**.
      </Step>

      <Step>
        Choose how to set up the new Okta connector:

        * Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren't yet managed with C1)

        * Add the connector to a managed app (select from the list of existing managed apps)

        * Create a new managed app
      </Step>

      <Step>
        Set the owner for this connector. You can manage the connector yourself, or choose someone else from the list of C1 users. Setting multiple owners is allowed.

        If you choose someone else, C1 will notify the new connector owner by email that their help is needed to complete the setup process.
      </Step>

      <Step>
        Click **Next**.
      </Step>

      <Step>
        In the **Settings** area of the page, click **Edit**.
      </Step>

      <Step>
        Click **Rotate** to generate a new Client ID and Secret.

        Carefully copy and save these credentials. We'll use them in Step 2.
      </Step>
    </Steps>

    ### Step 2: Create Kubernetes configuration files

    Create two Kubernetes manifest files for your Okta connector deployment:

    #### Secrets configuration

    ```yaml expandable theme={"theme":{"light":"css-variables","dark":"css-variables"}}
    # baton-okta-secrets.yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: baton-okta-secrets
    type: Opaque
    stringData:
      # C1 credentials
      BATON_CLIENT_ID: <C1 client ID>
      BATON_CLIENT_SECRET: <C1 client secret>
      
      # Okta credentials
      BATON_API_TOKEN: <Okta API token>
      BATON_DOMAIN: <Your Okta domain>

      # Optional: include if you want C1 to provision access using this connector
      BATON_PROVISIONING: true

      # Optional: exclude Okta push groups (APP_GROUP type) from sync
      # BATON_SKIP_APP_GROUPS: true

      # Optional: include inactive (disabled) Okta applications in sync
      # BATON_SYNC_INACTIVE_APPS: true
    ```

    See the connector's README or run `--help` to see all available configuration flags and environment variables.

    #### Deployment configuration

    ```yaml expandable theme={"theme":{"light":"css-variables","dark":"css-variables"}}
    # baton-okta.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: baton-okta
      labels:
        app: baton-okta
    spec:
      selector:
        matchLabels:
          app: baton-okta
      template:
        metadata:
          labels:
            app: baton-okta
            baton: true
            baton-app: okta
        spec:
          containers:
          - name: baton-okta
            image: ghcr.io/conductorone/baton-okta:latest
            imagePullPolicy: IfNotPresent
            env:
            - name: BATON_HOST_ID
              value: baton-okta
            envFrom:
            - secretRef:
                name: baton-okta-secrets
    ```

    ### Step 3: Deploy the connector

    <Steps>
      <Step>
        Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
      </Step>

      <Step>
        Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the Okta connector to. Okta data should be found on the **Entitlements** and **Accounts** tabs.
      </Step>
    </Steps>

    **Done.** Your Okta connector is now pulling access data into C1.
  </Tab>
</Tabs>

### What's next?

If Okta is your company's identity provider (meaning that it is used to SSO into other software), the connector sync will automatically create applications in C1 for all of your SCIMed software. Before you move on, review the [Create applications](/product/admin/applications) page for important information about how to set up connectors for the SCIMed apps.