Okta

Connects to your Okta tenant to pull users, groups, SSO applications, and MFA factor status. Surfaces dormant active users — accounts that never log in but still have app access — which is the dominant SMB IdP cleanup problem.

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 how many MFA factors they have enrolled. 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.

What this adapter does NOT pull

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

• Sign-in event logs (/api/v1/logs). The data is too large to be useful at the asset level, and the dormant-user signal is computable from user.lastLogin without it. We may add a slim auth-log feed in a follow-up if there's a specific finding it would unlock.
• Authentication policies, network zones, or device-trust rules (read separately if needed via a future "Okta posture" adapter).
• 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 Apps API (/api/v1/apps) — used for SSO application inventory.

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. 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).
• Your MFA adoption metric rises by every user that has at least one enrolled factor (phone, hardware token, U2F, WebAuthn).
• 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.

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.

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 |

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, well under any of these ceilings.

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 ceiling (60 req/min) which is one reason we don't currently pull it. If we add log ingestion in the future, polling cadence will be tuned separately for that endpoint.