Okta SCIM Integration
This guide covers the practical Okta setup for provisioning users and groups into AxonFlow Enterprise.
Before You Configure Okta
Have these ready:
- Okta admin access
- an AxonFlow SCIM token created from the customer portal
- the real enterprise portal hostname for the tenant you are provisioning into
Your SCIM base URL should look like this:
https://YOUR_PORTAL_OR_ENTERPRISE_DOMAIN/scim/v2
Step 1: Add the Okta SCIM App
- open the Okta Admin Console
- go to Applications
- add the SCIM 2.0 Test App (Header Auth) template
- name it for the AxonFlow environment you are onboarding
If you manage multiple AxonFlow environments, create clearly named apps such as:
AxonFlow ProductionAxonFlow StagingAxonFlow Pilot
Step 2: Configure API Integration
In the Okta app's provisioning settings:
| Field | Value |
|---|---|
| SCIM Base URL | https://YOUR_PORTAL_OR_ENTERPRISE_DOMAIN/scim/v2 |
| Unique identifier field for users | userName |
| Authentication mode | HTTP Header |
For the authorization header, use the full bearer-token format:
Bearer scim_your_token_here
That matches the current SCIM middleware, which expects an Authorization header with the Bearer scheme.
Step 3: Test the Connection
Before assigning real users:
- run Okta's API credential test
- confirm the test succeeds
- if it fails, validate discovery and
/Usersmanually with curl
If discovery works but the Okta test fails, the most likely issue is still header or token configuration.
Step 4: Configure User Provisioning
Enable the standard user lifecycle actions you want Okta to manage:
- create users
- update user attributes
- deactivate users
This is usually the right starting point for an enterprise rollout. Password sync is not the key integration concern here because AxonFlow SCIM is about provisioning and lifecycle, not password transfer.
Step 5: Review Attribute Mapping
The most important mappings are:
| Okta attribute | AxonFlow SCIM attribute |
|---|---|
user.login | userName |
user.email | emails[type eq "work"].value |
user.firstName | name.givenName |
user.lastName | name.familyName |
When debugging provisioning issues, start here first. Many "SCIM failures" are actually attribute-shape problems.
Step 6: Assign a Pilot User
Do not begin with a company-wide assignment.
Start with:
- one pilot user, or
- one pilot group if you explicitly want to validate group sync
Then verify:
- the user appears in the right tenant
- the identity shape is correct
- update and deactivation flows behave correctly
Step 7: Add Group Push Only After User Sync Is Stable
If you want Okta groups to drive AxonFlow access:
- enable the relevant group provisioning or push flow in Okta
- select one pilot group
- confirm the group lands correctly
- then align synced groups to your AxonFlow role model
This avoids turning one SCIM misconfiguration into an access-governance issue.
Recommended Production Rollout Pattern
For a controlled rollout:
- validate the connection in a pilot environment or with a pilot token
- provision one or two test users
- validate update and deactivation
- validate one test group
- rotate to a production token
- expand assignment gradually
Common Okta Issues
Test API credentials fails
Check:
- the base URL ends with
/scim/v2 - the enterprise hostname is correct
- the authorization value includes
Bearer - the token is not expired or revoked
Users are assigned but do not appear
Check:
- provisioning is enabled
- the pilot user is really assigned to the app
- attribute mappings are valid
- Okta provisioning logs for the specific user
Group sync is inconsistent
Check:
- whether group provisioning or push groups is actually enabled
- whether the pilot group is in scope
- whether you are trying to debug user sync and group sync at the same time
What Good Looks Like
A healthy Okta rollout should give you:
- reliable user creation
- reliable user updates
- predictable deactivation
- optional group sync with clear admin review
- a token-management workflow that your IAM or platform team can rotate safely
