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.

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.

Capabilities

Resource	Sync	Provision	Delete
Accounts
Applications
Groups
Roles
Standard and custom admin roles
Secrets - API tokens

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.

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.

The Okta connector supports automatic 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 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 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).

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.

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
Provision group membership
Review application assignment
Provision application assignment
Review admin roles
Create Okta group (action)
Modify Okta group (action)
Delete Okta group

To learn more about Okta roles, visit the Okta documentation on administrator roles and permissions.

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.

(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.

1. In Okta, log in to the Admin Dashboards and navigate to Security > Administrators > Roles.

2. Click Create new role.

3. Give the new role a name and description, such as “C1 integration read-only admin”.

4. Give the role the View roles, resources, and admin assignments permission (this is found in the Identity and access management permissions section).

5. Click Save role.

6. Next, navigate to Security > Administrators > Resources.

7. Click Create new resource set.

8. Give the new resource set a name and description, such as “Read-only admin for C1 integration”.

9. Click Add resources.

10. Find the Identity and access management resource type and select All Identity and Access Management resources.

11. Click Save selection, then click Create. The resource set is now shown on the Resources tab.

12. 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.

13. In the Complete the assignment section of the page, select the role and resource set you just created.

14. Click Save changes.

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.

1. Navigate to Directory > People and click Add person.

2. 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.

3. Set the Password for the account and carefully save it somewhere secure.

4. Click Save.

   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.

5. Navigate to Security > Administrator and click Add administrator.

6. Enter the email address for your newly created Service Account to select the user.

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

8. Click Add Administrator.

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.

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.

1. 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 to make sure you’re creating a token with the right permissions for your needs.

2. In the Okta console, navigate to Security > API and click Tokens.

3. Click Create Token.

4. Give your token a name, such as C1, and click Create Token.

5. Copy and save the new API token.

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.

1. In Okta, navigate to Applications > Applications and click Create App Integration.

2. Select API Services and click Next.

3. Give the app a name (e.g., “ConductorOne Integration”) and click Save.

4. On the app’s General tab, note the Client ID.

5. In the Client Credentials section, select Public key / Private key as the client authentication method.

6. 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.

7. Note the Key ID shown for your key.

8. 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)
9. 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).

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

Configure the Okta connector

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

Cloud-hosted

Follow these instructions to use a built-in, no-code connector hosted by C1.

1. In C1, navigate to Integrations > Connectors and click Add connector.

2. Search for Okta v2 and click Add.

3. 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

4. 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.

5. Click Next.

6. Find the Settings area of the page and click Edit.

7. Select your authentication method: API Token or OAuth 2.0 Private Key.

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

9. 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).
10. Optional. If desired, click the checkbox to Sync custom roles.

11. Optional. If desired, click the checkbox to Skip secondary emails when syncing user information.

12. 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.

13. 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.

14. Optional. Enable Sync secrets to display them on the Inventory page.

15. 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.

16. Click Save.

17. The connector’s label changes to Syncing, followed by Connected. You can view the logs to ensure that information is syncing.

Done. Your Okta connector is now pulling access data into C1.

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: For stable binaries (Windows/Linux/macOS) and container images.

• GitHub repository: Access the source code, report issues, or contribute to the project.

Step 1: Set up a new Okta connector

1. In C1, navigate to Integrations > Connectors > Add connector.

2. Search for Baton and click Add.

3. 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

4. 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.

5. Click Next.

6. In the Settings area of the page, click Edit.

7. Click Rotate to generate a new Client ID and Secret.

   Carefully copy and save these credentials. We’ll use them in Step 2.

Step 2: Create Kubernetes configuration files

Create two Kubernetes manifest files for your Okta connector deployment:

Secrets configuration

# 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

# 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

1. Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.

2. 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.

Done. Your Okta connector is now pulling access data into C1.

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 page for important information about how to set up connectors for the SCIMed apps.