SCIM Overview — SCIM Token, Provisioning, and Authentication
SCIM 2.0 (System for Cross-domain Identity Management) automates user and group provisioning between your identity provider and SecureCodingHub. Add, update, and remove users without manual intervention — authenticated by a single SCIM token issued from your org settings.
What is SCIM?
SCIM automatically syncs user lifecycle events from your identity provider to SecureCodingHub: create a user on hire, update attributes on change, and deactivate on offboarding. It eliminates manual user management entirely.
Supported Operations
SecureCodingHub's SCIM 2.0 endpoint supports the following resources and operations:
| Resource | Operations |
|---|---|
| Users | Create, Read, Update, Delete, List, Filter |
| Groups | Create, Read, Update, Delete, List |
| Service Provider Config | Read (discovery) |
| Schemas | Read (discovery) |
| Resource Types | Read (discovery) |
Authentication
The SCIM API uses Bearer token authentication. Generate a token from the SecureCodingHub admin panel and configure it in your identity provider.
| Setting | Value |
|---|---|
| Base URL | https://api.securecodinghub.com/api/sch/scim/v2 |
| Auth Header | Authorization: Bearer {your-scim-token} |
How It Works
Setting up SCIM provisioning is a straightforward four-step process:
Admin generates a SCIM token in SecureCodingHub
Token is configured in the identity provider (Okta, Azure AD)
IdP pushes user/group changes to SecureCodingHub SCIM endpoint
Users and teams are created, updated, and removed automatically
Why SCIM matters for compliance evidence
SCIM is not just an operational convenience. For organizations operating under SOC 2, ISO 27001, or HIPAA, automated deprovisioning is the control auditors actually test. ISO 27001 Annex A 9.2.6 calls for the removal of access rights upon termination of employment, and SOC 2 Common Criteria 6.2 and 6.3 expect logical access to be revoked in a timely manner when no longer required. Manual offboarding processes fail this test more often than people expect, because the evidence trail relies on a ticket being filed and a human remembering to click through every downstream tool.
When SCIM is wired to your identity provider, offboarding becomes a single event: HR marks the user as terminated in the HRIS, the IdP propagates the deactivation, and SecureCodingHub sets the user inactive within the next provisioning cycle. Auditors get a clean log of automated deactivations correlated to IdP events, which is exactly what they want to see during a Type II observation window. If you are preparing for a first-time SOC 2 audit, turning SCIM on early and letting it produce six months of clean logs is one of the cheapest evidence-generation wins available.
Common deployment patterns
Three deployment patterns cover most environments. Greenfield rollouts are the simplest: there are no existing users in SecureCodingHub, SCIM is enabled before the first invitations go out, and every user originates from the IdP. This is the cleanest model and the one we recommend whenever it is feasible. Partial sync is the next pattern: you scope SCIM to a single group or department, validate that lifecycle events behave correctly, and expand from there. This is useful for organizations with thousands of seats where a misconfigured attribute mapping could affect many accounts at once.
The third pattern is merging SCIM with existing manual users. SecureCodingHub matches incoming SCIM users to existing accounts on the email address, so the merge is generally non-destructive. The risk is that manually created users with mismatched casing, alias addresses, or stale email values will create duplicates. Before flipping the switch, export your current user list, reconcile it against the IdP roster, and resolve any address mismatches in the IdP. For details on configuring providers, see the Okta SCIM setup and Azure AD SCIM setup guides.