AtomationDocsOkta API access guide

Set up read-only Okta API access

Create the Okta API Services app Atomation uses to read your configuration, capture evidence, and run the first assessment. About 15 minutes for an Okta administrator.

Customer handoffOkta assessmentEvidence ready

Before you begin

This is the assessment data connection — a scoped Okta API Services app, separate from SSO and SCIM sign-in. Okta validates every request against the tenant JWKS URL Atomation gives you, and Atomation keeps the private key encrypted. You are never asked for an admin password.

You'll need:

An Okta Identity Engine org. Classic Engine is not supported.
An Okta admin who can create an API Services app and grant API scopes — a Super Admin can always grant scopes.
The tenant values below, generated by Atomation for your org.

Values you'll use

Atomation generates these per tenant. Keep them open while you work through the steps.

Setting	Value
Tenant subdomain	TENANT-SUBDOMAIN
Tenant JWKS URL	https://TENANT-SUBDOMAIN.atomation.io/.well-known/okta-jwks.json
App name	CLIENT Okta Assessment Service - ENVIRONMENT
Okta org URL	https://OKTA-ORG.okta.com or https://OKTA-ORG.oktapreview.com

Read scopes

Grant read scopes only — no write or manage scopes. Scopes allow the token's claims; the admin role you assign in Step 3 controls what the app can actually read.

In many orgs only a Super Admin can grant Okta API scopes. If the Grant button is unavailable, have a Super Admin grant the scopes below.

Scope	Reads
`okta.users.read`	Users and lifecycle state.
`okta.groups.read`	Groups and group membership.
`okta.apps.read`	Applications, assignments, and app configuration.
`okta.policies.read`	Sign-on, authenticator, password, and app policy posture.
`okta.logs.read`	System Log evidence for review windows.
`okta.networkZones.read`	Network zone posture.
`okta.trustedOrigins.read`	Trusted origin posture.
`okta.roles.read`	Admin role assignments and custom roles.
`okta.authorizationServers.read`	Authorization server posture.
`okta.idps.read`	Identity provider and routing posture.

Setup steps

Step 1

Create the API Services app

In the Okta Admin Console, open Applications → Applications, click Create App Integration, choose API Services, and name it CLIENT Okta Assessment Service - ENVIRONMENT.

Screenshot placeholderCreate API Services app

Okta Admin Console — selecting the API Services integration type.

Step 2

Register the JWKS URL and copy the Client ID

Under Client Credentials, set Public key / Private key, choose Use a URL to fetch keys dynamically, and paste your tenant JWKS URL. Save, then copy the Client ID.

Screenshot placeholderDynamic public key URL

Client Credentials screen with the JWKS URL set to fetch keys dynamically.

Step 3

Assign an admin role

On the Admin Roles tab, assign the least-privilege role your team approves that still gives the read visibility the assessment needs.

Step 4

Grant the read scopes

On the Okta API Scopes tab, Grant each scope from the list above. Enable DPoP if your org and the Atomation connection both support it.

Screenshot placeholderOkta API Scopes

The granted read scopes on the API Services app.

Step 5

Verify in Atomation

Paste the Client ID into Atomation and click Verify Connection.

Screenshot placeholderAtomation verification

Verification result: token acquired, scopes usable, role sufficient.

Verify

You're connected when Atomation confirms all four:

Token acquired — the service app authenticates against your org.
Scopes usable — the granted read scopes return data.
Role sufficient — the admin role allows the reads (no 403).
Verified timestamp — Atomation records the last successful check.

Atomation then captures the first snapshot, and your report appears in your workspace.

Troubleshooting

Error	Likely cause	Fix
`invalid_client`	Client ID mismatch, JWKS URL not saved, or public key not reachable.	Re-check the Client ID, tenant JWKS URL, and Client Credentials settings.
Scope denied	A required read scope was not granted to the service app.	Open the Okta API Scopes tab and grant the missing scope.
`403` on read calls	Token is valid, but the admin role is missing or too narrow.	On Admin Roles, assign an approved role with sufficient visibility.
DPoP failure	The Okta DPoP setting and the Atomation connection capability don't match.	Confirm whether DPoP is enabled for the app and supported for this connection.

Okta reference

Next steps

Finish onboarding

Frameworks, manual evidence, and first-scan readiness.

Optional: SSO & SCIM

Let your team sign in to Atomation through Okta.

Reading reports

What the assessment produces and how to use it.