Pulling your directory from Okta, JumpCloud, Auth0 or another identity provider
Read-only directory sync from seven identity providers: Okta, JumpCloud, Auth0, OneLogin, Keycloak, PingOne and AWS IAM. What each needs and what it does not carry over.
If your people already live in Okta, JumpCloud, Auth0, OneLogin, Keycloak, PingOne or AWS IAM, you can pull them into Qorionix without hand-entering or bulk-importing a CSV. Each of the seven providers below has a real, read-only directory connector: it lists users and groups, maps them into Qorionix's directory, and can run again on demand or on an incremental schedule using the provider's own change cursor.
What each provider needs
| Provider | Credential | Where to create it |
|---|---|---|
| Okta | An API token (SSWS) | Okta admin console → Security → API → Tokens → Create Token. A read-only admin's token is enough. |
| JumpCloud | An API key | JumpCloud → Settings → API Settings → copy the API key. The key carries the permissions of the admin who generated it — use a read-only administrator. |
| Auth0 | A Machine to Machine application authorized for the Management API with read:users and read:roles | Auth0 dashboard → Applications → create a Machine to Machine application, authorize it for the Management API, grant those two scopes. |
| OneLogin | A Read Users API credential (region-aware: us or eu) | OneLogin → Developers → API Credentials → create a Read Users credential; note which region your account is in. |
| Keycloak | A confidential client whose service account holds the realm-management view-users and query-groups client roles | Your realm's admin console → Clients → create a confidential client with a service account, then grant it those two client roles. |
| PingOne | A Worker application with the p1:read:user and p1:read:group roles | PingOne admin console → Applications → add a Worker application with those roles; note the environment ID and region. |
| AWS IAM | An access key for an IAM user or role holding the AWS managed policy IAMReadOnlyAccess (or a policy scoped to iam:ListUsers, iam:ListRoles, iam:ListGroups, iam:GetGroup) | AWS console → IAM → create a user or role, attach the policy, create an access key. |
For every provider except Okta, JumpCloud and AWS IAM, connecting requires an OAuth2 client-credentials grant, so a region setting matters: OneLogin and PingOne serve different regional hosts, and picking the wrong one fails the connection cleanly rather than silently reading the wrong tenant.
Connecting one
Open the provider's catalogue entry
Under Integrations → Catalog, find the provider and choose Directory sync (it is a separate capability from Sign-on, on the same row, if the provider also does SSO).
Fill in the credential and region
Enter the fields from the table above. Press Test and save — the test performs a real, bounded read against the provider before storing anything.
Run the first sync
Once saved, press Sync now to run the first pull. After that, an incremental sync runs on a schedule using the provider's own cursor, so only records changed since the last run are re-read.
What is different about each one
- Auth0 has no native group object on its base plan. Roles stand in for groups — the connector reads Auth0 roles and the users assigned to each one, which is the nearest equivalent every tenant with role-based access in Auth0 already has populated. If you use Auth0's Organizations feature for structure instead of roles, that is not read by this connector.
- AWS IAM has no per-user enabled/disabled flag the way an identity provider does — an IAM user either exists or does not. Every user this connector lists comes into Qorionix marked active; AWS IAM Identity Center (federated sign-in) is a separate integration this connector does not touch.
- OneLogin, Keycloak and PingOne each resolve group membership through their own membership-lookup endpoint rather than a group object that lists members directly — this is normal for these providers and does not change what you see in Qorionix.
- Okta and JumpCloud were already available for single sign-on and inbound SCIM before this directory pull existed; the directory pull fills the one remaining gap on those catalogue rows.