Skip to demo content
Step 1 of 8: Admin assigns Alice to the app in Okta
← All demos

SCIM Provisioning with Okta

1. Admin assigns Alice to the app in Okta

An Okta administrator opens the application in the Okta Admin Console and assigns alice@contoso.com to it. Alice is not involved and may not even know this is happening. The assignment does two independent things: it entitles Alice to sign in via SAML later, and -- because provisioning is enabled on this app -- it queues a provisioning job. From this point on, everything is asynchronous: Okta will work through the job in the background with server-to-server calls, and the admin console will eventually show success or a provisioning error.

What the user sees

https://contoso-admin.okta.com/admin/app/ots_scim/instance/0oa7xyz/#tab-assignments
Demo simulation — do not enter real credentials
okta
AD
🔐

Onetime Secret

Provisioning: enabled
General Sign On Provisioning Assignments

People

AS
Alice Smith
alice@contoso.com
Assigned
No other people assigned

What's happening (HTTP)

  1. REQUEST Admin Browser → Okta
    POST https://contoso-admin.okta.com/api/v1/apps/0oa7xyz/users
    Content-Type: application/json
    Cookie: sid=okta_admin_session
    {
  "id": "00u1abcd2EFGHIJKL345",
  "scope": "USER"
}
    Admin console assigns Okta user 00u1abcd2EFGHIJKL345 (alice@contoso.com) to the app
  2. INTERNAL Okta → Okta
    Queue provisioning job
    Provisioning is enabled with "Create Users", "Update User Attributes", and "Deactivate Users" checked. Okta maps its profile attributes to SCIM attributes per the app’s attribute mappings and schedules the outbound SCIM calls.

Legend

Browser request
Server response
Server-to-server
Internal
← All demos
An educational demo, not a reference implementation v0.3.0