SCIM Provisioning

nexusID speaks SCIM 2.0 in both directions:

• Inbound — nexusID is a SCIM server: an upstream identity system (Microsoft Entra ID, Workday, Okta, …) provisions users and groups into nexusID.
• Outbound — nexusID is a SCIM client: nexusID provisions users and groups out to downstream SaaS apps (the same role Okta plays when it "pushes" to an app).

If you've configured provisioning in Okta ("Choose provisioning options" — SCIM connector base URL, an authentication mode, and push actions), that screen is Okta acting as the client. In nexusID terms that maps to either side depending on direction — see the mapping table at the end.

---

A. Inbound — provision into nexusID (nexusID = SCIM server)

Use this when an upstream IdP/HR system should create, update, and deactivate users in nexusID.

1. Endpoints

Base URL: https://<your-nexusid-host>/scim/v2 (e.g. https://demo.nexusid.ai/scim/v2).

Resource	Endpoints
Discovery	GET /ServiceProviderConfig, GET /ResourceTypes, GET /Schemas
Users	GET/POST /Users, GET/PUT/PATCH/DELETE /Users/{id}
Groups	GET/POST /Groups, GET/PUT/PATCH/DELETE /Groups/{id}

Schemas: core User, the enterprise User extension (department, manager, employeeNumber, …), and core Group. Inbound writes drive the joiner/mover/leaver lifecycle (source=scim).

2. Authentication — Bearer token (HTTP Header)

Inbound SCIM uses an API key as a Bearer token, validated per request (the route is open at the firewall, authenticated at the controller). The upstream sends:

Authorization: Bearer idk_xxxxxxxxxxxx

(X-API-Key: idk_… is also accepted.)

3. Create the token (admin)

1. Admin → API Management (/admin/api-management).
2. Create API key → name it, add scope scim:provision, optionally set an expiry, rate limit, and allowed IPs.
3. Copy the full key — it's shown once. Paste it into the upstream system's Authorization field.

4. Point the upstream at nexusID

In the upstream connector, set:

• SCIM base URL: https://<your-nexusid-host>/scim/v2
• Authentication: HTTP Header / Bearer token → the idk_… key above
• Unique identifier: userName (email) or externalId

Limitations (inbound): equality filters only (userName eq, emails eq, externalId eq); no Bulk; no sort or attribute selection.

---

B. Outbound — provision out to a downstream app (nexusID = SCIM client)

This is the direct analog of the Okta provisioning screen. You configure a Provisioning Target for each downstream app and nexusID pushes to it.

1. Create a provisioning target (admin)

Admin → Provisioning Targets (/admin/jit-ui/targets) → Add target:

Field	Meaning (≈ Okta)
Endpoint URL	the app's SCIM connector base URL (nexusID calls …/Users, …/Groups)
Protocol	SCIM_2_0 (also REST / Webhook)
Auth type	BEARER_TOKEN, BASIC_AUTH, OAUTH2_CLIENT_CREDENTIALS, API_KEY, or NONE (≈ Okta's Basic / HTTP-Header / OAuth2)
Credentials	the token / username+password / OAuth2 token_url+client_id+client_secret+scope — stored encrypted
Attribute mapping	JSON mapping nexusID claims → downstream SCIM attributes
Password sync	opt-in: also PATCH the password attribute

2. Push actions

Action	How nexusID does it	≈ Okta
Create user	POST {endpoint}/Users	Push New Users
Update / deactivate user	PATCH {endpoint}/Users/{id} (active=false on leaver)	Push Profile Updates / deactivate
Password sync	PATCH {endpoint}/Users/{id} (password), opt-in	—
Push group	POST/PATCH {endpoint}/Groups — upsert by displayName, members resolved to the target's user ids	Push Groups

User create/deactivate and password sync run automatically through the JIT/lifecycle flow. Group push is available on demand via:

POST /admin/jit/targets/{targetId}/push-group
{ "displayName": "Engineering", "members": ["alice@acme.com", "bob@acme.com"] }

It upserts the SCIM Group by displayName and sets its members to those users' ids at the target (members not yet present at the target are skipped — provision them first).

Limitations (outbound): group push is on-demand (auto-push on every membership change is a follow-up); REST/Webhook targets don't support group push.

---

Okta provisioning screen → nexusID

Okta "Choose provisioning options"	nexusID inbound (server)	nexusID outbound (client)
SCIM connector base URL	nexusID gives you …/scim/v2	you set the target's Endpoint URL
Auth: Basic / HTTP-Header / OAuth2	Bearer API key (scim:provision)	Bearer / Basic / OAuth2-CC / API-Key
Import new users + profile updates	inbound POST/PUT/PATCH → JML	—
Push New Users / Profile Updates	—	POST create / PATCH update
Push Groups	inbound Groups	/push-group
Where to configure	Admin → API Management	Admin → Provisioning Targets