> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/integrations/iam/okta.md).

# Okta

Connect Okta to Siit to sync your users, groups, and application assignments, and expose the full set of Okta actions directly inside Siit workflows, request side panels, and the IT Agent.

<figure><img src="https://451675063-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fz9xmM8V3atukfr2XaElR%2Fuploads%2FVWYw9U4iBxKgwkG2H86w%2FSiit_Okta.jpg?alt=media&amp;token=cd9dd835-3264-4374-acba-5cb596857f68" alt=""><figcaption></figcaption></figure>

### What you get

* **Live directory** — Okta users, groups, and app assignments sync into Siit with full attribute coverage.
* **One-click actions from any request** — provision, revoke, add to group, reset password, reset MFA, directly from the request side panel.
* **Workflow-driven automation** — use Okta actions in any workflow: approvals, Day-1 onboarding, access requests, offboarding, SLA escalations.
* **IT Agent native support** — Okta actions are first-class in IT Agent playbooks, with optional approval gating on every action.
* **Audit trail** — every action triggered from Siit is logged on the request timeline.

### What syncs from Okta

| Category     | Fields                                                                      |
| ------------ | --------------------------------------------------------------------------- |
| Identity     | Display name, email, login, Okta user ID, employee number                   |
| Profile      | Job title, department, manager, location (city, country), custom attributes |
| Groups       | Okta groups, memberships, types (built-in, custom, app-assigned)            |
| Applications | App assignments per user, including SAML, OIDC, and SWA apps                |
| Status       | Active, provisioned, staged, suspended, deprovisioned                       |

Work email is the canonical identifier.

### Actions available

Siit exposes the following Okta actions — available in the request side panel, in workflows, and in IT Agent playbooks. Each can be gated behind an approval.

**User actions**

* Activate user
* Suspend user
* Deprovision user
* Reset password (sends reset email or sets temp password)
* Reset MFA (clears enrolled factors, forces re-enrollment)
* Create temporary access code (lets a locked-out user enrol a new authenticator)
* Revoke sessions (force sign-out everywhere)
* Restore sessions

**Create temporary access code** hands the employee a value only they should read. Siit delivers it privately — a Slack or Teams direct message behind a **Reveal** button, or a reply on the request only the requester can open — and takes it back when it expires. Okta sets the expiry on the code, and that expiry wins over your workspace setting. See [Secret codes](/request-management/secret-codes.md).

**Group actions**

* Add user to group
* Remove user from group

**Application actions**

* Assign application to user
* Remove application from user

### Before you connect

* You'll need an Okta **Super Admin** (or an admin with Read + Manage permissions for Users, Groups, and Applications) to authorize the connection.
* Decide whether Siit should use **OAuth** (recommended — managed via an Okta service app) or an **API token** (legacy — tied to an individual admin account).
* You choose which scopes to grant when you connect. The modal lists them one per line with a checkbox, and Siit runs only the actions the scopes you approve allow. `okta.users.read` is the one exception: without it Siit cannot resolve the Okta user behind a request, so no action can run.
* Make sure the scopes you grant are allowed by your Okta tenant's API token / OAuth policy.

### Connect Okta

#### Option A — OAuth (recommended)

1. In Siit, go to **Settings → Workspace → Integration library**.
2. Find **Okta** in the IAM section and click **Connect**.
3. Enter your Okta **domain** (e.g., `yourcompany.okta.com`).
4. You'll be redirected to Okta to sign in and consent. Sign in with a Super Admin account.
5. Review the requested scopes and select the ones you want to grant:
   * `okta.users.read`
   * `okta.users.manage`
   * `okta.groups.manage`
   * `okta.apps.manage`
   * `okta.sessions.manage`
   * `okta.eventHooks.manage`
   * `okta.authenticators.read` — for **Create temporary access code**
6. Accept and you'll be redirected back to Siit.
7. Siit runs an initial import of users, groups, and apps.
8. Review the imported data and click **Finish setup**.

> **Note** - each `.manage` scope also covers reads on the same object, so there is no separate `okta.groups.read` or `okta.apps.read` to grant.

> **Note** - `okta.authenticators.read` was added after the first Okta connections shipped. If you connected Okta before it existed, add it to your Okta API service app, then reconnect and tick it — **Create temporary access code** cannot find your org's authenticator without it. Every other action keeps working meanwhile.

#### Option B — API token (legacy)

Use this only if OAuth isn't an option in your tenant.

1. In Okta, go to **Security → API → Tokens → Create Token**. Name it "Siit integration" and copy the token.
2. In Siit → **Settings → Workspace → Integration library → Okta → Connect**, choose **API token** and paste the token plus your Okta domain.
3. Click **Authorize** and follow the initial import flow.

> **Tip** — API tokens inherit the permissions of the admin who created them, and they expire after 30 days of inactivity. OAuth is less fragile and survives admin changes — we recommend it for all new installs.

### After the connection

* **Check your People list** — confirm user counts match Okta's active users.
* **Scope the groups and apps** — by default everything is synced. In **Settings → Workspace → Integration library → Okta**, you can scope to specific groups, apps, or user types if you don't want the entire tenant.
* **Try one-click actions** — open any request, and use the side panel Apps section to run Okta actions on the requester.
* **Build your first workflow** — the classic starter: access request → manager approval → Okta assign application → DM requester.

### Sync frequency

Okta data refreshes automatically every few hours.

To pull the directory in straight away, open the **⋯** menu on the Okta card in **Settings → Workspace → Integration library** and pick **Synchronize**. The action hides itself while a sync is running and for 15 minutes after the last one.

**App removals sync too.** If an app is deleted in Okta, it's marked **Restricted** in Siit on the next sync, so your catalog doesn't keep offering an app that no longer exists in your identity provider. This only applies to apps that were discovered and are managed through the Okta integration; apps added directly in Siit or sourced from another integration keep their current status.

### Common workflows

**App access request.** *Trigger: Request submitted (service = "Request app access"). Actions: manager approval → Okta assign application → DM requester.*

**Group access request.** *Trigger: Request submitted. Actions: approval → Okta add to group → confirmation.*

**Password reset (self-service).** *Trigger: Request submitted (service = "Reset password"). Actions: identity verification → Okta reset password (emails user) → close request.*

**MFA reset with manager approval.** *Trigger: Request submitted (service = "Reset MFA"). Actions: manager approval → Okta reset MFA → DM requester with re-enrollment instructions.*

**Day-1 onboarding (with HRIS).** *Trigger: Start date. Actions: Okta activate user → add to baseline groups → assign department app bundle → notify manager.*

**Offboarding on end date.** *Trigger: End date. Actions: Okta revoke sessions → remove from all groups → deprovision user → equipment pickup request.*

**Suspicious activity response.** *Trigger: Request submitted (service = "Report lost device"). Actions: Okta revoke sessions → suspend user → create incident for security team.*

### IT Agent integration

Okta actions are available inside IT Agent playbooks via slash commands:

* `/okta reset multi-factor` *(approval available)*
* `/okta reset password` *(approval available)*
* `/okta add to group` *(approval available)*
* `/okta add applications` *(approval available)*

This means an IT Agent playbook can resolve a full password reset or access request end-to-end, with approval gates where you need them. See IT Agent.

### Troubleshooting

**Connection fails on authorize.** The admin doesn't have Super Admin rights, or the tenant blocks the requested scopes. Try with a Super Admin, or check Security → API → Authorization Servers for scope restrictions.

**Users missing from Siit.** Check whether suspended, deactivated, and staged users are excluded (they are by default). Adjust the status filter in **Settings → Workspace → Integration library → Okta** if needed.

**Action fails with "insufficient scope".** The action needs a scope that was not granted when Okta was connected, either because it was unchecked in the connection modal or because your tenant blocks it. Reconnect Okta and grant the missing scope.

**Create temporary access code fails with a 403.** Either the temporary access code feature is not enabled on your Okta org, or the admin role behind the connection is missing `okta.users.credentials.manageTemporaryAccessCode`. Both surface the same Okta error — check the org feature first.

**Action fails silently in a workflow.** Open the workflow run in **Workflows → \[workflow] → Runs** — errors from Okta are shown inline with the Okta response code.

**API token expired.** If you're on API token auth, rotate the token (Okta → Security → API → Tokens) and update it in Siit. Consider migrating to OAuth to avoid future expirations.

**Group/app not visible in the action picker.** It's likely scoped out. Review scoping in **Settings → Workspace → Integration library → Okta**, or confirm the object is actually an Okta group / app and not an Okta Workflows object.

**Rate limits.** Large tenants may occasionally hit Okta rate limits during initial sync. Siit retries automatically; contact support if syncs are consistently slow.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.siit.io/integrations/iam/okta.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.