How DSALTA integrates with Okta — data collected, setup guide, and automated compliance checks.
Overview
How to connect
Automated checks
Useful links
DSALTA connects to Okta using read-only API access to collect compliance evidence automatically. Data feeds into your Data Library modules.
Read-only access. DSALTA never modifies, creates, or deletes resources in your Okta environment.
DSALTA collects this integration’s data when you connect it — you can refresh it at any time with Sync from integrations on the Integrations page. The compliance checks below re-run once a day at 02:00 America/New_York.
DSALTA reads the Okta user roster — names, emails, account status and creation dates, which appears on your Access page. DSALTA does not read Okta admin-role assignments, so every person is listed with the role User.It calls these Okta endpoints:
/api/v1/users
/api/v1/users/{id}/factors
/api/v1/policies
Permissions the checks require:okta.apps.read, okta.groups.read, okta.policies.read, okta.users.readEvery request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Okta environment.
There is no Reconnect button. Open Integrations → Connected, click Manage on the Okta card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from Okta. This usually happens when API tokens expire.
Data is not syncing
Verify the connected account still holds the permissions this integration requires. Then open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Sync from integrations at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
DSALTA requests these scopes: okta.users.read, okta.groups.read, okta.apps.read, okta.policies.read, offline_access.Before you begin
An Okta OAuth app inside your own Okta org, registered with DSALTA. Okta API scopes can only be granted to an app that lives in your org, so this connection needs a Web (OIDC, authorization-code) app integration in your Okta org with the four okta.*.read scopes granted, and DSALTA must hold that app’s Client ID and Client Secret. The connect panel only asks for your subdomain — if an app has not been registered for your org yet, arrange that with DSALTA before you start.
1
Start in DSALTA
Open Integrations in the DSALTA sidebar, find Okta, and click Connect to open the connect panel.
2
Find your Okta subdomain
Use your Okta org domain WITHOUT -admin — enter only the subdomain label: for the sign-in URL acme.okta.com you type just acme, because the field already supplies https:// and .okta.com (lowercase letters, digits, - and _ only). Do NOT use the admin console host acme-admin.okta.com. The -admin host does not serve OAuth and returns a 404. You’ll enter this subdomain in the Connect window.
Only *.okta.com orgs can be entered here — the field’s suffix is fixed to .okta.com. If you reach Okta through a custom sign-in domain, use the underlying <org>.okta.com host; Okta preview/sandbox orgs on *.oktapreview.com cannot be connected.
3
Authorize as an Okta administrator
When you click Connect, sign in with an Okta admin and grant read-only access. The OAuth app must have the okta.users.read, okta.groups.read, okta.apps.read, and okta.policies.read API scopes granted (Okta Admin → Applications → your app → Okta API Scopes). A non-admin cannot grant these org-wide read scopes.Granting those API scopes to the app is a one-time action that only a Super Admin can perform — Okta restricts scope grants to the Super Admin role. Once the grant is in place, a Read-Only Administrator is enough to sign in and authorize the connection.
The admin you sign in with bounds what the token can actually do. Okta issues the token with whatever scopes the app was granted, but a request still fails if the signed-in admin’s role lacks the underlying permission — so sign in with an admin who holds at least Read-Only Administrator across users, groups, apps and policies.
The admin you sign in with must also be assigned to that OAuth app in Okta (app → Assignments). Okta refuses sign-in for users who are not assigned to the app, so authorization fails with a “user is not assigned to this application” error even for a Super Admin.
The app must authorize against Okta’s org authorization server (https://<org>.okta.com/oauth2/v1/authorize), not a custom authorization server — Okta’s docs are explicit that “only the org authorization server can mint access tokens that contain Okta API scopes”. An app pointed at a custom authorization server will authorize but its token will not carry the okta.*.read scopes.
4
Finish in DSALTA
Return to the connect panel you opened in step 1, enter your Okta subdomain, and click Connect — Okta takes over, you sign in and approve the read-only access, and the connection completes when Okta redirects back.
Once connected, Okta appears on the Connected tab and the checks below begin reporting after the first sync.
Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.
.png?fit=max&auto=format&n=tsMQJyneJ1xquFUo&q=85&s=4d401cc03b547d99b6f75a6bd170c334)
