> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-leet-mcp-server-outreach.mintlify.site/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.
**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](/product/admin/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](/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. 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](/product/admin/automations-steps-reference#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 "" --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](https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm).
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](/baton/okta#api-token-permissions-and-conductorone-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
**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. `.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](/product/admin/inventory).
**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](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
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
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**.
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
```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:
BATON_CLIENT_SECRET:
# Okta credentials
BATON_API_TOKEN:
BATON_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
```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: 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](/product/admin/applications) page for important information about how to set up connectors for the SCIMed apps.