Set up an Okta connector

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
Resource sets
Resource set bindings
Secrets - API tokens
Devices

Devices is opt-in. This resource type is off by default. Enable it by selecting the Device resource type in the connector’s sync configuration. Devices are synced read-only; the connector does not manage device-to-user assignments.

Resource sets and resource set bindings require Sync Custom Roles. These two resource types model Okta’s custom-role machinery: a resource set is the collection of Okta objects a custom role applies to, and a binding pairs a resource set with a custom role. Granting a binding assigns a user or group to that custom role over that resource set. Both are synced and provisioned only when Sync Custom Roles is enabled.

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. The Okta connector supports account deprovisioning through C1 resource deletion. It first deactivates the user to the DEPROVISIONED state and then permanently deletes the user. The same operations are available separately through the deactivate_user and delete_user connector actions. These operations require an API token or OAuth app with okta.users.manage scope.

Account creation profile fields

When you configure account provisioning for Okta, C1 shows the following optional fields on the account creation form (in addition to first name, last name, email, and login):

Field	Values	Default	What it does
Password Change Required on Login	`True` / `False`	Off	When creating an account with a random password, requires the user to change that password on first login.
Create Inactive	`True` / `False`	Off	Creates the user in Okta as staged (inactive) without activating them.
Send Activation Email	`True` / `False`	`True`	When set to `False`, activates the user without sending Okta’s activation email. Use this when C1 (or another system) owns user communication.
Provider Type	`OKTA` / `FEDERATION`	Okta’s default (local) provider	Set to `FEDERATION` to create a federated user with no local Okta password. Common in hub-and-spoke / Org2Org designs where the hub IdP owns credentials.
Additional Attributes	Map of Okta profile keys	—	Extra Okta profile attributes (standard or custom schema) to set on the user.

Provider Type FEDERATION cannot be combined with a random-password credential option (federated users have no Okta password). Send Activation Email False cannot be combined with Password Change Required on Login True when creating with a random password (that combination cannot set Okta’s change-password-on-login flag). With a no-password credential option, Password Change Required on Login has no effect and does not conflict. If Create Inactive is True, the connector leaves the user staged and does not run the activation step — Create Inactive takes precedence over Send Activation Email.

Okta Staged status (sign-in to Okta, not C1). In Okta, Staged means the account was created but not activated yet, so the user cannot sign in to Okta. That is an Okta lifecycle state — it is not about signing in to ConductorOne. Staged users sync as disabled in C1 so sync matches the lifecycle actions: disable_user is a no-op on staged accounts, and enable_user activates them (/lifecycle/activate without sending another activation email). After activation the account becomes Active or Provisioned (Provisioned only means they have not completed first login yet).Default Create Account does not leave users staged: the connector activates them or sends Okta’s activation email. Users stay staged only when Create Inactive is True, an Okta admin created them without activating, or an incomplete create left them there. The raw Okta status string stays on the resource details, so Staged remains distinguishable from Suspended or Deprovisioned. After you upgrade a connector that previously reported staged users as enabled, the next sync flips those resources to disabled — review any automations that key off user enabled/disabled status.

Recovering an account left staged by an interrupted create. With Send Activation Email set to False, account creation spans several calls, so a failure partway through can leave the Okta user created but not activated.Retrying the same create does not finish the job. Okta rejects the duplicate login, the connector returns the account it found, and the user stays Staged — a staged account left behind this way is indistinguishable from one created deliberately with Create Inactive.Run the enable_user action against the account to finish activating it.

Password Change Required on Login, Create Inactive, and Send Activation Email are all string fields with a True / False placeholder (same schema shape). Map them as the strings "true" / "false" (case-insensitive). The connector also accepts a real boolean at runtime, but provisioning mappings that treat these three fields the same way are the supported pattern. Additional Attributes must return a map. Account creation fails with an error when a mapped value has the wrong type, so the account is never created without the values you asked for. Leaving a field unmapped uses its default.

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. The Okta connector’s actions are reached from two different automation steps, and which step offers an action is determined by the action itself — you cannot choose:

Automation step	Actions offered	How the target is selected
Perform connector action	`deactivate_user`, `delete_user`, `create`, `modify_group`	Varies by action. The two user actions use a resource selector on the User resource type. `modify_group` takes the Okta group ID as a plain text field, and `create` has no target at all.
Account lifecycle action	`enable_user`, `disable_user`	The step’s own Target account selector — either the account in context or a specific account.

In the Perform connector action step, actions are listed under their resource type and display name rather than their raw action name: deactivate_user and delete_user appear as user - Deactivate User and user - Delete User, and modify_group as group - Modify Group. An action with no display name registered falls back to its raw name, so create appears as group - create. enable_user and disable_user take user_id as a plain string, and modify_group takes group_id the same way. Pass the raw Okta ID (for example 00u1abc2def3GHI4jk5), not the C1 resource ID — the connector sends the value to Okta unchanged, and a C1 resource ID returns a not-found error. deactivate_user and delete_user take a resource selector instead, so the Okta ID is resolved for you.

Action name	Additional fields	Description
enable_user	`user_id` (string, required)	Enables an Okta user account: unsuspends a suspended account, and activates a staged one without sending an activation email. Returns success without calling Okta when the account is already enabled. Does not reactivate a deactivated (`DEPROVISIONED`) account — that returns an error. Okta’s activate API can do that transition, but this action treats reactivation of a deactivated user as a separate decision from enable.
disable_user	`user_id` (string, required)	Suspends an Okta user account. Returns success without calling Okta when the account is already suspended, deactivated, or still staged.
deactivate_user	`user_id` (Okta user resource, required)	Destructively deprovisions the selected user from assigned applications and leaves the Okta user record in `DEPROVISIONED`. A user already in that state succeeds without another mutation.
delete_user	`user_id` (Okta user resource, required)	Ensures the selected user is deactivated, then permanently deletes the user. A user that is already absent succeeds so workflow retries are safe.
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).

deactivate_user, delete_user, and C1 account deprovisioning are destructive. Deactivation removes the user’s assigned-app provisioning and can destroy downstream data such as email or files. Deletion permanently removes the Okta user and cannot be recovered. Use workflow approval gates where appropriate.

disable_user is not an alias for deactivation: it suspends sign-in while retaining group and application assignments, and enable_user can reverse it. Use deactivate_user only when the workflow intends Okta deprovisioning, and delete_user only when it intends permanent removal.

deactivate_user is not available from the Account lifecycle action step — that step offers only enable_user and disable_user. An existing offboarding automation built on Account lifecycle action therefore reaches Okta suspend, not deprovision. To deprovision from a workflow, add a Perform connector action step and select user - Deactivate User.

enable_user does not clear a credential problem. Okta treats Recovery, Password expired, and Locked out as enabled statuses — the account exists and is not suspended, it just cannot complete a sign-in. enable_user reports those accounts as already enabled and makes no call to Okta, so it neither unlocks the account nor resets the password.Clear these in Okta, or with a password-reset or unlock flow. enable_user covers only the two transitions it names: unsuspending a Suspended account and activating a Staged one.

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.

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

Click Create new role.

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

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

Click Save role.

Next, navigate to Security > Administrators > Resources.

Click Create new resource set.

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

Click Add resources.

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

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

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.

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

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.

Navigate to Directory > People and click Add person.

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.

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

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.

Navigate to Security > Administrator and click Add administrator.

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

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

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.

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.

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

Click Create Token.

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

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.

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

Select API Services and click Next.

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

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

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

Leave the DPoP setting at its default. The connector supports Demonstrating Proof of Possession (DPoP), so you do not need to change the Proof of Possession option — whether “Require Demonstrating Proof of Possession (DPoP) header in token requests” is checked (Okta’s default for new API Services apps) or unchecked, the connector authenticates successfully. If you disabled DPoP for an existing app on the advice of an earlier version of this page, you can safely re-enable it.

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.

After clicking Add Key, click Done in the key dialog and then click Save in the outer Client Credentials panel. Okta’s UI requires both clicks; missing the outer Save silently discards the key and the connector will fail with "The client does not have a JWKSet configured, but the client_assertion requires one".

Note the Key ID shown for your key.

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.logs.read (required for continuous 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)
okta.devices.read (required when the Device resource type is enabled)

After clicking Grant for each scope, refresh the page and visually verify that all granted scopes appear under “Granted scopes.” Okta’s API Services app config can silently discard incomplete saves. If scopes are missing, the connector will fail with "You are not allowed any of the requested scopes".

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

This step is required, and skipping it does not always produce an error. Granting OAuth scopes is not sufficient on its own — the scopes are present in the token, but Okta still evaluates the app’s admin role when serving each request.Without an admin role assignment, and even when all OAuth scopes are granted correctly:

Most endpoints fail with "You do not have permission to perform the requested action" (HTTP 403). Device sync fails this way.
User sync instead returns an empty list with HTTP 200. The sync completes successfully and reports no error, but the connector finds zero accounts.

If a sync finishes cleanly with no accounts, check the app’s Admin Roles tab before looking anywhere else.

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

Private key format. The connector accepts a PEM-encoded RSA private key in either format, so no conversion is needed:

PKCS#1 — header line -----BEGIN RSA PRIVATE KEY-----
PKCS#8 — header line -----BEGIN PRIVATE KEY----- (what OpenSSL 3.0+ produces by default)

The key must be RSA. Okta’s DPoP implementation does not accept elliptic-curve keys, and the connector rejects an EC key with "Okta DPoP requires RSA".

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
Self-hosted

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

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

Search for Okta v2 and click Add.

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

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.

Click Next.

Find the Settings area of the page and click Edit.

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

Enter your Okta domain hostname, e.g. <YOUR DOMAIN>.okta.com, into the Okta domain field. The https:// prefix is optional.

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

Optional. If desired, click the checkbox to Sync custom roles.

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

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.

Optional. Inactive (disabled) Okta applications are synced by default. Clear the Sync inactive apps checkbox to exclude them.

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

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.

Click Save.

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.

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

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

Search for Baton and click Add.

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

Click Next.

In the Settings area of the page, click Edit.

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: inactive (disabled) Okta applications are synced by default.
  # Set this to false to exclude them.
  # BATON_SYNC_INACTIVE_APPS: "false"

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: public.ecr.aws/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

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

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.

Welcome

Manage connectors

Deploy connectors

Upload connector data

Configurable connectors

Pre-built connectors

Set up an Okta connector

Capabilities

Account creation profile fields

Connector actions

Authentication methods

Gather Okta credentials

API token permissions and C1 capabilities

(Optional) Create a custom read-only admin role

(Optional) Create a service account for the API token

Create an API token

(Alternative) Set up an OAuth 2.0 OIDC app

Configure the Okta connector

Resources

Step 1: Set up a new Okta connector

Step 2: Create Kubernetes configuration files

Secrets configuration

Deployment configuration

Step 3: Deploy the connector

What’s next?

​Capabilities

​Account creation profile fields

​Connector actions

​Authentication methods

​Gather Okta credentials

​API token permissions and C1 capabilities

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

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

​Create an API token

​(Alternative) Set up an OAuth 2.0 OIDC app

​Configure the Okta connector

​Resources

​Step 1: Set up a new Okta connector

​Step 2: Create Kubernetes configuration files

​Secrets configuration

​Deployment configuration

​Step 3: Deploy the connector

​What’s next?

Capabilities

Account creation profile fields

Connector actions

Authentication methods

Gather Okta credentials

API token permissions and C1 capabilities

(Optional) Create a custom read-only admin role

(Optional) Create a service account for the API token

Create an API token

(Alternative) Set up an OAuth 2.0 OIDC app

Configure the Okta connector

Resources

Step 1: Set up a new Okta connector

Step 2: Create Kubernetes configuration files

Secrets configuration

Deployment configuration

Step 3: Deploy the connector

What’s next?