# Okta

the platform reads your Okta org's users through the Okta Users API so you can review who has access.

:::caution
Create an **Okta API token** in the Admin Console under **Security** > **API** > **Tokens**. the platform sends it with Okta's `SSWS` authorization scheme, so an OAuth 2.0 access token issued by your org authorization server will **not** work. An API token also carries the permissions of the admin who created it and is rejected once that admin is deactivated, so create it from an account that stays active.
:::

## Prerequisites

- the platform organization administrator access
- An Okta admin role that can create tokens. Okta allows super admins, org admins, group admins, group membership admins, and read-only admins to create them
- An admin who can view **Users**, because the token inherits that admin's permissions
- Your **Okta Domain**, which the Connect dialog asks for alongside the token. Okta has no central API gateway, so every org authenticates against its own host, such as `acme.okta.com`, `acme.oktapreview.com`, `acme.okta-emea.com`, or a custom domain. Click your username in the upper right corner of the Admin Console and the domain appears in the dropdown

## Collected Fields

| the platform field | Okta field                                               | Notes                                                                                                                                                                                                                  |
| ----------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name        | `profile.displayName`                                    | Falls back to `profile.firstName` and `profile.lastName` joined with a space                                                                                                                                           |
| Email       | `profile.email`                                          | Falls back to `profile.login`. A user with neither is skipped                                                                                                                                                          |
| Role        |  |                                                                                                                                                                                                                        |
| Admin       |  |                                                                                                                                                                                                                        |
| Status      | `status`                                                 | `SUSPENDED` and `DEPROVISIONED` are listed as inactive. `ACTIVE`, `PROVISIONED`, `STAGED`, `RECOVERY`, `PASSWORD_EXPIRED`, and `LOCKED_OUT` are listed as active. A user Okta returns without a status is left unknown |
| MFA         |  |                                                                                                                                                                                                                        |
| Last login  | `lastLogin`                                              | The user's last sign-in to Okta. Left empty when Okta returns `null`                                                                                                                                                   |
| External ID | `id`                                                     | Stable identifier used to track the account across reviews                                                                                                                                                             |
| Created at  | `created`                                                | When the user was created in the Okta org                                                                                                                                                                              |

The users endpoint does not return role assignments, so the platform records no role and flags no account as an administrator.

## Step 1: Create an API Token

1. In the Okta Admin Console, signed in as an admin who can view **Users**, go to **Security** > **API** > **Tokens**.
2. Click **Create token** and name the token in **What do you want your token to be named?** (e.g. `Probo Access Review`).
3. For ZebraByte Cloud, set **API calls made with this token must originate from** to **Any IP**. For a self-hosted deployment with fixed egress addresses, you can instead allowlist those addresses in an Okta network zone. Click **Create token**, then copy the token value and store it securely. Okta shows it only once.

## Step 2: Connect in the platform

1. In the platform, go to **Access Reviews** > **Sources** > **Add Source**.
2. Find **Okta**, click **API Key**, paste the token, enter your **Okta Domain** (the org host, for example `acme.okta.com`), and click **Connect**.

the platform names the source after your Okta org and pulls its users into your campaigns.

## Troubleshooting

- **Token rejected.** Confirm it is an Okta API token created under **Security** > **API** > **Tokens** rather than an OAuth 2.0 access token, and that the **Okta Domain** is the host of the org that issued it. A token authenticates only against its own org.
- **A token that used to work stops working.** An Okta API token is valid for 30 days from its creation or its last use, so a token unused for 30 days expires. Okta also rejects a token once the admin who created it is deactivated. Create a new one from an account that stays active.
- **No users appear.** The token carries the permissions of the admin who created it, so it must come from an admin who can view Users. For ZebraByte Cloud, the token's network condition must allow **Any IP**. For a self-hosted deployment, it can instead allowlist that deployment's fixed egress addresses.
- **Deactivated users are missing.** Okta's users endpoint omits users whose status is `DEPROVISIONED` unless the request carries a filter or search query, and the platform sends neither, so accounts you deactivated in Okta do not reach the campaign.
