Okta

Connects to your Okta tenant to pull users, groups, SSO applications, each user's enrolled MFA factor types, admin role assignments, and Sign-On/Access policy configuration. Surfaces dormant active users, standing admin roles on inactive accounts, and policies that don't require MFA — the dominant SMB IdP cleanup problems.

What this adapter actually does for you

Once connected, Clariti polls your Okta tenant every hour for:

1. Every user in your directory, with their status (ACTIVE, SUSPENDED, DEPROVISIONED, etc.), last sign-in timestamp, and which MFA factor types they have enrolled (e.g. push, TOTP, WebAuthn, SMS) — including whether their only enrolled factor is phone-based (SMS/voice), a materially weaker configuration than a hardware key or authenticator app. This is the building block for every other identity finding.
2. Every group — both Okta's built-in groups and the custom groups you use to drive app assignments.
3. Every SSO application your tenant has set up, with its sign-on mode (SAML, OIDC, SWA, etc.) and visibility.

From this data, Clariti emits one high-severity finding per active dormant user: any account marked ACTIVE in Okta that hasn't signed in for 90 days. Two scenarios cover ~95% of these:

• Departed employees / contractors who never got deprovisioned because the offboarding email got missed. They retain access to whatever apps Okta provisions, which is the single most common SMB phishing-payload vector.
• Provisioned-but-never-used accounts — new hires whose account was created weeks in advance and now exists with no activity. Same risk surface.

Clariti caps the per-user finding at 25 individuals; if you have more than 25 dormant users (which is unusual for an SMB), you get a 26th roll-up finding pointing you to the Okta admin panel for a bulk operation.

Configuration-risk checks

Beyond the dormant-user finding, Clariti checks two configuration signals:

• Standing admin roles on dormant users. For each dormant user (see above), Clariti checks whether they still hold an active administrator role (e.g. Super Administrator, Organization Administrator). A departed or inactive account that still has admin rights is a materially worse risk than an ordinary dormant account — if the credential is ever compromised, whoever holds it inherits admin access with no active user around to notice. This produces its own finding, separate from and in addition to the general dormant-user finding.
• Sign-On and Access policies that don't require MFA. Clariti reads your Global Session (Sign-On) Policies and, on Identity Engine orgs, your Access Policies, along with each active policy's rules. If a policy has no rule requiring a second authentication factor, Clariti flags it — anyone governed by that policy can sign in with a password alone. If Clariti can't read a policy or its rules (e.g. a permissions issue), it never guesses "no MFA" from the failure — it logs a warning instead so you're never told a policy is insecure when Clariti simply couldn't see it.

System Log anomaly detection

Beyond the checks above, Clariti scans your Okta System Log (/api/v1/logs) on every poll for two specific, security-meaningful patterns over a rolling 24-hour window — not a raw dump of every event Okta logs:

• Repeated failed sign-ins. Any account with 5 or more failed sign-in attempts (user.session.start failures) in the last 24 hours gets a high-severity finding — the same threshold pattern used to detect credential-stuffing and password-guessing attacks, sitting below Okta's own default account-lockout threshold so you see the attack in progress, not just its aftermath.
• Account lockouts. Any account that reaches its Okta-configured lockout limit (user.account.lock.limit) in the last 24 hours gets its own finding — this is a rarer, already-escalated signal, so no additional threshold is applied.

Both patterns are aggregated per account, not per event — a spray attack generating thousands of failed-login events produces one finding per affected account (capped at 10 individually, with a roll-up finding for the rest), never a flood of one-per-event findings. If Clariti can't read the System Log for a poll (e.g. a permissions issue or an unexpected response shape), it records a partial-coverage warning and skips the check for that poll — it never guesses "no anomalies" from a read it couldn't complete.

What this adapter does NOT pull

We stay narrow on Okta. The adapter does not pull:

• The full Okta System Log. Clariti queries /api/v1/logs for exactly two filtered event patterns (see "System Log anomaly detection" above) over a rolling 24-hour window — it does not ingest or store the raw event stream, and does not surface individual log events as their own findings or assets.
• Network zones or device-trust rules (read separately if needed via a future "Okta posture" adapter). Sign-On/Access policy content is pulled (see above) — this exclusion is now narrower than it used to be.
• Password history or password hashes. We never have, never will.
• Anything that would require a write scope on the API token. Clariti's API token has read-only access.

If you want any of those signals today, you'd reach for Okta's reporting features directly. Clariti's lane is the asset-and-finding view across your stack — Okta is one feed into that, not the whole picture.

Permissions required

Okta API tokens inherit the permissions of the admin who created them. Clariti only needs:

• Read-only access to the People API (/api/v1/users, /api/v1/groups) — used for user and group inventory.
• Read-only access to the Factors API (/api/v1/users/{id}/factors) — used to read each user's enrolled MFA factor types. Same token, no extra scope to grant.
• Read-only access to the Apps API (/api/v1/apps) — used for SSO application inventory.
• Read-only access to the Roles API (/api/v1/users/{id}/roles) — used to check for standing admin roles on dormant users. Same token, no extra scope to grant.
• Read-only access to the Policy API (/api/v1/policies, /api/v1/policies/{id}/rules) — used to check whether Sign-On/Access policies require MFA. Same token, no extra scope to grant.

Best practice: create the token from a Read-only Administrator account — Okta provides this role specifically to scope down API token blast-radius. Don't use a Super Admin token. A Read-only Administrator can read all of the above (including role assignments and policies); if your token was instead created by a narrower custom admin role, a 403 on the roles or policy checks specifically will show up as a partial-coverage warning in the run log rather than a hard failure — the rest of the sync still completes normally. If your Okta tenant doesn't have a dedicated read-only admin account yet, this is a good time to create one.

Step-by-step credential creation

Connecting in Clariti

In Clariti, navigate to Integrations → Okta → Connect now and paste the two values:

Click Connect. Clariti verifies the token by issuing a single test call to /api/v1/users?limit=1. A green checkmark means the token is valid; an actionable error message tells you what to fix if not.

What you'll see after connect

Within ~2 minutes:

• The Assets screen fills with one row per Okta user, group, and SSO app, each labelled Okta in the source chip.
• The Identity coverage tile on the dashboard turns green (Okta now contributes alongside any Microsoft 365 or Google Workspace adapter you have connected).
• Each user's enrolled MFA factor types are captured and stored on their asset record, including whether their only active factor is phone-based (SMS/voice) — a materially weaker configuration than a hardware key or authenticator app. This data is available on the asset via the API for downstream use.
• If you have dormant active users, Findings populates with one card per dormant user (up to 25 individuals + an aggregate card if you have more). Each finding includes the username, the last-login timestamp, and a step-by-step remediation checklist.
• If any dormant user still holds an admin role, a separate high-severity finding calls that out specifically.
• If any Sign-On or Access policy has no rule requiring MFA, a finding names the policy and links you to where to fix it in the Okta admin console.
• If any account has repeated failed sign-ins or hits its Okta lockout limit in the last 24 hours, a finding names the account and links you to the System Log entries behind it.

Troubleshooting

401 Unauthorized — E0000011: Invalid token provided The token has expired (Okta tokens expire after 30 days of inactivity — a token Clariti has been polling won't expire under normal use). If polling stops for any reason (kill switch, Railway env outage), the 30-day clock starts. Recreate the token via Steps 1-3 above and update it in Clariti's adapter settings.

403 Forbidden The admin who created the token doesn't have permission to read the resource. Most often the token was created by a custom admin role that excludes Read-only Administrator privileges. Either expand the admin's role or have a Read-only Administrator create the token instead. A 403 specifically on the admin-roles or Sign-On/Access-policy checks doesn't fail the whole sync — Clariti logs a partial-coverage warning and skips just that finding rather than guessing at an answer it couldn't actually read.

429 Rate Limited Almost always caused by another tool polling Okta on the same subdomain (Okta's rate limits are per-tenant, not per-token). Clariti respects Okta's X-Rate-Limit-Reset header and retries up to 3 times with the recommended backoff. If you hit this persistently, check whether you're running other Okta-API-using tools (Terraform, scim-sync, custom scripts) and stagger their schedules.

"Connection failed" on the initial Connect Most often a typo in the subdomain field. The subdomain is just the part before .okta.com — don't paste acme.okta.com or https://acme.okta.com. Clariti validates the subdomain to be DNS-label-shaped (letters, digits, hyphens only) and rejects values that would point at non-Okta domains; if you see "is not a valid DNS subdomain label" in the error, double-check what you pasted.

Using an Okta developer / preview tenant (*.oktapreview.com) or EMEA tenant (*.okta-emea.com) The connect modal defaults to the .okta.com suffix. If your tenant is on .oktapreview.com (free developer tenants) or .okta-emea.com (EU customers), the default lookup fails with "is not a recognized Okta domain". Contact Clariti support with your full tenant URL (e.g. dev-12345678.oktapreview.com) so we can override the suffix on your adapter — the SSWS token itself works against any Okta cloud.

No dormant findings even though you know there are old accounts The dormant check only flags users with status=ACTIVE. Deprovisioned, suspended, or staged users don't show up as findings even if they haven't logged in. That's by design — if Okta already marks them as inactive, your offboarding process already worked. Open the user in Okta and check the status badge.

API rate limits and polling cadence

Okta enforces per-endpoint, per-tenant rate limits. The relevant ceilings for Clariti's adapter:

| Endpoint | Production tier limit | Free dev tier limit | |--------------------------------|------------------------|----------------------| | /api/v1/users | 600 req/min | 100 req/min | | /api/v1/groups | 600 req/min | 100 req/min | | /api/v1/apps | 600 req/min | 100 req/min | | /api/v1/users/{id}/factors | 600 req/min | 100 req/min | | /api/v1/users/{id}/roles | 600 req/min | 100 req/min | | /api/v1/policies | 600 req/min | 100 req/min | | /api/v1/logs | 120 req/min (org), 60 req/min (per token) | lower on free dev tier |

Clariti polls once per hour by default. A typical SMB tenant (under 500 users, 50 groups, 30 apps) uses ~5–10 paginated requests per poll for the inventory endpoints, plus one /factors request per user (no bulk factors endpoint exists) — Clariti caps this fan-out to 10 requests in flight at a time and to the first 1,000 users per poll, so even the largest SMB tenants stay well under any of these ceilings.

The admin-roles check adds one /roles request per dormant user only (not every user), capped at the first 200 dormant users per poll — SMB admin populations are small, so this fan-out is negligible in practice even on a tenant with thousands of total users. The Sign-On/Access-policy check adds a handful of /policies and /policies/{id}/rules requests per poll (capped at 50 policies per type) — SMB tenants typically have only a few policies configured.

When Clariti hits a 429, the adapter reads Okta's X-Rate-Limit-Reset header (epoch seconds, more accurate than Retry-After), waits the indicated duration (capped at 60s), and retries up to 3 times. Persistent throttling beyond the retry budget surfaces as a recognizable 429 error in the run log rather than a generic failure — so if you ever see this you'll know exactly what's happening.

The /api/v1/logs endpoint has a lower per-token ceiling (60 req/min) than the other endpoints above, which is why the System Log anomaly check (see "System Log anomaly detection") bounds itself to two filtered queries per poll, each capped at 5 pages of up to 1,000 events — well under that ceiling even on a noisy tenant. This endpoint gets the same X-Rate-Limit-Reset-aware retry as every other Okta endpoint Clariti calls.