Okta Connector

The Okta connector reads Okta users, groups, and group membership through the Okta Core API.

Provider Path

Okta Core API v1

Typical resources:

/api/v1/users
/api/v1/groups
/api/v1/groups/{id}/users

Roster uses Okta live when an admin searches Okta users or groups from the Platform participant picker. When the admin adds a selected user or group to a participant, Roster caches that selected record in directory_records and directory_record_sources. When the selected record is a group, Roster also caches the selected group’s direct members and membership edges for participant resolution.

MCP and REST directory-record search uses only Roster’s cached/materialized directory records. It does not call Okta live.

Production Requirements

• Okta org URL, for example https://example.okta.com
• API token stored in the runtime environment or secret manager
• refresh schedule for selected users, groups, and group memberships
• stable Okta user and group IDs

The connector uses SSWS API token authentication against the Okta Core API. Use the least-privilege Okta admin role and token lifecycle controls that allow Roster to read the users, groups, and memberships needed for participant resolution.

Secret Kinds

Supported secret kind:

api_key

Store the token value outside Roster, then reference it from the connector:

env:OKTA_API_TOKEN

Normalized Data

The connector normalizes Okta records into Roster directory users and groups:

queryUsers(query)
getUser(externalId)
queryGroups(query)
getGroup(externalId)
getGroupMembers(externalId, query)

Users are normalized from Okta id, profile.login, profile.email, and profile.displayName or profile.firstName plus profile.lastName. Groups are normalized from Okta id, profile.name, and profile.email.

Live search supports query text, exact external ID lookup, and paginated results. Page size is capped at 200 records, and Okta Link: rel="next" pagination is carried as the next cursor.

Use participant membership to map Okta users or groups to Roster participants.