Okta SCIM Setup
Configure automatic user and group provisioning from Okta to SecureCodingHub using SCIM 2.0.
Prerequisites
- Okta admin account
- SecureCodingHub org admin account
- SSO configured (recommended but not required)
Step 1 — Generate a SCIM Token
Log in to SecureCodingHub as Org Admin
Go to Settings → SCIM
Click Generate Token
Copy the token — it is shown only once
Step 2 — Configure SCIM in Okta
Go to Okta Admin → Applications → your SecureCodingHub app
Go to Provisioning tab → Configure API Integration
Check Enable API integration
SCIM connector base URL: https://api.securecodinghub.com/api/sch/scim/v2
Unique identifier field: email
API Token: paste your SCIM token
Click Test API Credentials — should show "Verified"
Save
Step 3 — Enable Provisioning Features
Enable the following provisioning features in Okta for full lifecycle management:
| Feature | Recommended |
|---|---|
| Create Users | Enable |
| Update User Attributes | Enable |
| Deactivate Users | Enable |
| Push Groups | Enable — syncs teams |
Step 4 — Test Provisioning
Assign a test user to the app in Okta
Check SecureCodingHub Users page — user should appear
Update the user's name in Okta → verify it updates in SecureCodingHub
Remove user from app in Okta → verify user is deactivated
SCIM Settings in SecureCodingHub
Here is what the SCIM configuration panel looks like in the admin settings:
Pre-deployment checklist for Okta SCIM
Before you click Save in the Okta provisioning panel, walk through a short verification checklist. First, confirm the SCIM connector base URL is the exact value documented on the SCIM overview page. A trailing slash, a missing version path segment, or pointing at the wrong region will produce confusing 404 responses that Okta surfaces as generic credential errors. Second, verify that the SCIM token you pasted is the one you just generated and not a partially copied string. SCIM tokens are long and easy to truncate when copying from a modal.
Third, scope the token to the right SecureCodingHub organization. If your tenant has multiple orgs, the token is bound to the org that generated it and will not provision users into a different one. Fourth, plan attribute mapping before enabling provisioning. Decide whether userName should map to userPrincipalName or to mail. In most Okta tenants these are identical, but in organizations with proxy addresses or multi-domain configurations they diverge. Pick the value that matches the email users will sign in with, otherwise SSO and SCIM will create duplicate accounts.
Watching the first sync
A successful first sync is uneventful. In Okta, navigate to Provisioning and watch the Logs tab. You should see a sequence of Create user events resolving to status Success, each with a 201 response from the SecureCodingHub endpoint. On the SecureCodingHub side, new users appear in the Users page with their email and display name populated. The total time for the first sync depends on assignment count and Okta queue depth but is typically under two minutes for a small pilot group.
A failed attribute mapping looks different. Okta will report Create user as Failed, the log entry will include a SCIM error response, and the most common message is a 400 indicating a missing required attribute or an invalid format. Fix the mapping in the Provisioning tab, click Retry Failed Operations, and watch the next cycle complete. If errors persist, generate a fresh token, double-check the base URL, and confirm that the user you assigned has values in the attributes your mapping references.