Okta
Configure the Okta integration with RAD Security to import users, groups, and System Log events.
This guide walks you through connecting your Okta org to RAD Security so it can import user and group data and read the Okta System Log for identity visibility.
This page covers the Okta data integration. To let your team sign in to RAD Security with Okta, see Okta SSO Setup instead.
Choose a setup path
Okta offers two ways to authorize a machine-to-machine application, and the choice determines whether the integration can be read-only.
| Option 1: OIN API Service Integration | Option 2: Custom API Services App | |
|---|---|---|
| Setup effort | Low - install a catalog listing | Higher - create the app and grant scopes yourself |
| Scopes | Fixed by the listing, including okta.users.manage (write) | You grant each scope individually |
| Read-only possible | No | Yes - this is the only read-only route |
| Credential | Client secret | PEM private key (private_key_jwt) |
If your organization requires least-privilege or read-only access to Okta, you must use Option 2. The OIN listing's scopes are set by the listing itself and cannot be narrowed.
Prerequisites
Before you begin, ensure you have:
- Super Administrator access to your Okta org - only a Super Admin can grant API scopes
- Your Okta org URL (e.g.
https://your-org.okta.com) - Access to a RAD Security workspace with integration permissions
Option 1: OIN API Service Integration
The quickest path. Okta issues a client ID and client secret, and the scopes come pre-configured with the listing.
This listing's scopes include okta.users.manage, which grants write access to your users. You cannot narrow the scope set on an OIN integration. If you need read-only access, use Option 2.
Step 1: Install the Synqly Identity Connector
Access the Okta Admin Console
Log in to Okta with Super Administrator privileges and open the Admin Console.
Navigate to API Service Integrations
Go to Applications > API Service Integrations.
Add the Integration
- Click Add Integration
- Search for and select Synqly Identity Connector
- Click Next
Install and Authorize
Click Install and Authorize to complete the setup.
Save the Credentials
Okta displays the Client ID and Client Secret. Copy both to a secure location now.
Okta shows the client secret once. If you navigate away without copying it, you must generate a new one.
Step 2: Configure in RAD Security
Navigate to Data Sources > Integrations > IAM in your RAD Security workspace and enter:
| Parameter | Description |
|---|---|
| Client ID | The Client ID from Step 1 |
| Client Secret or Private Key (PEM) | The Client Secret from Step 1 |
| Base URL | Your Okta org URL (e.g. https://your-org.okta.com) |
RAD Security encrypts and stores these values. Rotate the client secret in Okta if you suspect exposure, then update the integration.
Option 2: Custom API Services App (Read-Only)
Create the application yourself and grant only the scopes you need. This is the only way to run the Okta integration read-only.
A client secret will not work for this path. A custom API Services app on the Okta org authorization server must authenticate with private_key_jwt. Posting a client_credentials request with a client secret to https://your-org.okta.com/oauth2/v1/token returns:
401 invalid_client
Client Credentials requests to the Org Authorization Server must use the
private_key_jwt token_endpoint_auth_method.
You must register a public key with Okta and give RAD Security the corresponding PEM private key.
Step 1: Pre-flight - check the public client app admin setting
Open Account Settings
Go to Settings > Account.
Confirm Public client app admins is DISABLED
Verify that Public client app admins is disabled.
If this setting is enabled, Okta automatically assigns Super Administrator to new API service apps once scopes are granted - the exact opposite of read-only. Confirm it is disabled before you create the app.
Step 2: Create the API Services app
Create the App Integration
Go to Applications > Applications > Create App Integration, select API Services, and give the app a descriptive name (e.g. "RAD Security Integration").
No user or group assignment is needed. An API Services app acts on its own behalf, not on behalf of a signed-in user.
Note the Client ID
On the app's General tab, copy the Client ID.
Step 3: Configure client authentication and generate a key
Set Client authentication to Public key / Private key
Under General Settings > Client Credentials, edit Client authentication and select Public key / Private key.
Add a key
Under PUBLIC KEYS, click Add, then Generate new key. Choose RSA.
Copy the PEM private key
Click the PEM button under Private key and copy the entire value, including the -----BEGIN and -----END lines.
Okta displays the private key once and does not store it. If you lose it, you must generate a new key pair.
Save
Click Save.
Step 4: Confirm DPoP is not required
Check Proof of possession
Under General Settings > Proof of possession, confirm that Require Demonstrating Proof of Possession (DPoP) header in token requests is unchecked.
This setting is off by default, so this is a confirmation rather than a change. If DPoP is ever enabled, token requests fail with 400 invalid_dpop_proof - never 401 invalid_client. Use that distinction to tell the two failure modes apart.
Step 5: Grant API scopes
Open the Okta API Scopes tab
On the app, go to the Okta API Scopes tab.
Grant each scope
Click Grant on each of the following:
okta.users.read- list and read usersokta.groups.read- list groups and group membersokta.logs.read- read the Okta System Log
Leave okta.users.manage off for a read-only integration.
Only a Super Administrator can grant API scopes, and selecting a scope is not the same as granting it. Each scope must show as granted before the integration will work.
Step 6: Assign an admin role
Open the Admin roles tab
On the app, go to the Admin roles tab and click Admin assignments granted to this app > Edit assignments.
Assign Read-only Administrator
Assign the Read-only Administrator role, then click Save Changes.
Scopes alone are not sufficient. Okta enforces the API scope and the admin role as an intersection - a request succeeds only if both allow it.
A custom admin role cannot be substituted here, because custom admin roles cannot be granted the View System Log permission. See Okta's support article and the admin role comparison.
Step 7: Configure in RAD Security
Navigate to Data Sources > Integrations > IAM in your RAD Security workspace and enter:
| Parameter | Description |
|---|---|
| Client ID | The Client ID from Step 2 |
| Client Secret or Private Key (PEM) | The full PEM private key from Step 3, including the -----BEGIN and -----END lines |
| Base URL | Your Okta org URL (e.g. https://your-org.okta.com) |
The Client Secret or Private Key (PEM) field carries either credential type. For this path it holds signing material, not a shared secret - paste the PEM private key exactly as Okta produced it.
Read-only trade-off
Omitting okta.users.manage makes the integration read-only and disables the connector's user-management actions:
- Disable and enable a user
- Force a password reset
- Expire a user's sessions
Reading users and groups and ingesting System Log events are unaffected. If you later need these actions, grant okta.users.manage and assign an admin role that permits them.
Operational limits
Verify Integration
After completing the setup, verify your integration is working:
- Navigate to Data Sources > Integrations > IAM in RAD Security
- Locate your Okta integration
- Check the connection status shows as Connected
- Confirm users and groups are syncing
Your Okta integration is now configured. RAD Security can sync identity data and audit events based on the scopes and admin role you granted.