SCIM: The User Provisioning Standard

May 31, 2023
Walter Manger
4 minute read

      You’ve set up SAML SSO with your enterprise customer. Employees can now log into your app with their company credentials. Great.

      Now a new employee joins the company, and they can’t log in. Your app has no record of them. IT has to manually create an account in your system. It’s a friction point that scales poorly.

      SCIM solves this.

      What SCIM Does

      SCIM (System for Cross-domain Identity Management) is a standard API for managing user identity across systems. It lets your identity provider automatically create, update, and deactivate users in your app without manual intervention.

      A typical SCIM flow:

      1. New employee joins the company
      2. HR creates them in Okta (or Active Directory, or Entra)
      3. Okta automatically hits your SCIM API: POST /Users with the employee’s details
      4. Your app creates the user
      5. When the employee leaves, Okta hits DELETE /Users/{id}
      6. Your app deactivates them

      Same for updates: change someone’s team in Okta, and SCIM syncs that to your app.

      SCIM vs SAML: Different Jobs

      This is the key insight: SAML handles authentication. SCIM handles provisioning.

      SAML answers: “Who are you?” Your identity provider proves the user’s identity, and your app trusts that proof.

      SCIM answers: “What’s your record?” Your identity provider keeps your app’s user directory in sync with the source of truth.

      They’re complementary:

      • SAML gets you logged in
      • SCIM ensures your account exists and is current

      Why SCIM Matters

      For enterprises: User lifecycle management at scale. Without SCIM, IT spends time manually creating and deleting accounts. With SCIM, it’s automatic.

      For compliance: Automated deprovisioning is a compliance requirement in many frameworks. If someone leaves the company, they should be immediately locked out of all systems. SCIM ensures that happens.

      For security: Manual account management is error-prone. Accounts linger, permissions drift, old employees retain access. SCIM reduces that surface.

      For SaaS providers: Enterprises expect SCIM. If you don’t support it, they’ll look for a competitor who does.

      SCIM 2.0 Basics

      SCIM 2.0 (the current standard) is simple: it’s a REST API for managing users and groups.

      Core endpoints:

      POST /Users              # Create a user
      GET /Users/{id}         # Fetch a user
      PUT /Users/{id}         # Update a user
      DELETE /Users/{id}      # Delete a user
      GET /Groups             # List groups
      POST /Groups            # Create a group
      

      A user object looks like:

      {
        "id": "2819c223-7f76-453a-919d-413861904646",
        "userName": "alice@company.com",
        "name": {
          "givenName": "Alice",
          "familyName": "Smith"
        },
        "emails": [
          {
            "value": "alice@company.com",
            "type": "work"
          }
        ],
        "groups": [
          "engineering",
          "platform"
        ],
        "active": true
      }
      

      That’s the schema. Implement these endpoints, and your app speaks SCIM.

      Implementing SCIM

      If you’re supporting enterprise customers:

      1. Use a library. Don’t write SCIM from scratch. Libraries exist for most languages.

        • Python: python-scim
        • Node.js: scim2-parse-filter
        • Go: github.com/elimity-com/scim
      2. Start simple. Implement POST /Users, PUT /Users/{id}, DELETE /Users/{id}, and GET /Users. That covers 90% of use cases.

      3. Add filtering. Okta and other identity providers query users with filters like filter=userName eq "alice@company.com". Implement filter support early.

      4. Test with Okta. If your first customer is an Okta org, test directly with Okta’s SCIM provisioning UI. It’s the gold standard.

      SCIM in the Wild

      Most modern SaaS apps support SCIM if they support SAML. Enterprise identity providers (Okta, Entra, Ping) all have SCIM connectors.

      The flow for an enterprise customer:

      1. You support SAML for SSO
      2. You support SCIM for user provisioning
      3. They configure both in their IdP
      4. New employees automatically get access
      5. When they leave, they automatically lose access

      It’s smooth, automated, and enterprise-friendly.

      When to Implement SCIM

      1. Early: Build it when you build SAML. They belong together.
      2. If delaying: Add SCIM before your first enterprise deal closes. It’s often a blocker.
      3. Maintain it: SCIM is simple once implemented, but it’s critical to identity lifecycle. Keep it working.

      The Bottom Line

      SCIM is boring infrastructure that enterprises expect. It’s not flashy, but it’s non-negotiable if you’re targeting enterprise customers.

      Think of it this way:

      • SAML: “I am who I say I am”
      • SCIM: “Here are all the people who are supposed to exist and what they’re allowed to do”

      Both are necessary for enterprise identity.