Skip to main content

SCIM Auto-Provisioning

Single sign-on lets users log in with their corporate identity. SCIM lets the corporate identity system manage their account itself — create them on hire, update their role on a transfer, deactivate them on the day they leave. All without an admin clicking anything in Dashify.

This page explains what SCIM is, how it complements SSO, and how Dashify implements it.

The problem SCIM solves​

Imagine a company with five hundred employees and ten SaaS tools. A new hire starts on Monday. Without SCIM, IT has to remember to:

  • Create the user in Tool A.
  • Create the user in Tool B.
  • Create the user in Tool C.
  • Set the right role in each.
  • ... etc, ten times.

When the same person leaves three years later, IT has to remember to:

  • Disable the user in Tool A.
  • Disable the user in Tool B.
  • Disable the user in Tool C.
  • ... etc, ten times.

If IT forgets even one of these on offboarding, that person retains access to corporate data after they leave. This is the dominant source of "zombie account" security incidents in enterprises.

SCIM is the standard that lets the company's directory (Okta, Microsoft Entra, OneLogin, JumpCloud) push user lifecycle events directly into every connected SaaS tool. Onboarding becomes automatic. Offboarding becomes automatic. Nothing depends on a human remembering.

What SCIM is​

SCIM stands for System for Cross-domain Identity Management. The current version is 2.0. It is a REST API specification — every SCIM-compliant service exposes the same set of endpoints, returns the same JSON shapes, and accepts the same operations.

The endpoints Dashify exposes are:

  • GET /scim/v2/ServiceProviderConfig — what the server supports.
  • GET /scim/v2/ResourceTypes — the kinds of resources (Users, Groups, etc.).
  • GET /scim/v2/Schemas — the field definitions.
  • GET /scim/v2/Users — list users.
  • GET /scim/v2/Users/{id} — get one user.
  • POST /scim/v2/Users — create a user.
  • PUT /scim/v2/Users/{id} — replace a user.
  • PATCH /scim/v2/Users/{id} — partially update a user.
  • DELETE /scim/v2/Users/{id} — delete a user.

The IdP knows how to call these endpoints because every SCIM 2.0 service exposes the same shape. The IdP just needs the base URL and an authentication token.

How a tenant connects SCIM​

The authentication is done with a Personal Access Token (covered on the next page). The Org Admin generates a PAT with SCIM scope, pastes it into the IdP's connector configuration, and from that point on the IdP can call SCIM endpoints as that admin.

The PAT is sensitive. If leaked, it gives someone the ability to create and disable users in your tenant. Dashify shows it only once at generation time and stores only a SHA-256 hash; if you lose it, you generate a new one.

What happens on a new hire​

The user can now sign in via SSO immediately. They have not had to set a Dashify password — they never will. Their corporate password is the only one they will ever use to access Dashify.

What happens on a role change​

When someone is promoted, transferred, or assigned a new responsibility, the IdP updates their record and pushes a PUT or PATCH to Dashify. The user's role is updated; their permissions change immediately.

If the role mapping is configured to read an IdP group claim, group membership changes flow through automatically.

What happens on offboarding​

This is the most important case.

The user's account is deactivated, not deleted. Soft-delete preserves the audit trail and any data they created. All their active sessions are revoked instantly — even if they had Dashify open in a browser tab when HR clicked terminate, their next request fails authentication and they are signed out.

Their PATs are also revoked. Their passkeys are disabled. Every authentication path is closed.

This is the value proposition of SCIM: a single click in the directory locks the user out of every connected SaaS tool. No human has to remember anything.

What Dashify supports vs. doesn't​

The SCIM 2.0 spec is enormous. Dashify's implementation is focused:

Supported:

  • User CRUD (create, read, update, delete).
  • The active toggle for activate/deactivate.
  • Filter by userName (the most common filter IdPs use) — GET /scim/v2/Users?filter=userName eq "alice@acme.com".
  • PATCH operations for partial updates.
  • The standard error envelope (application/scim+json).

Not (yet) supported:

  • Groups. Group membership in Dashify is currently controlled by role, not by SCIM groups.
  • Complex filter expressions beyond simple equality. The spec allows things like name.familyName sw "K" (starts-with on a nested field); we return 501 for those.
  • Bulk operations.

The unsupported pieces are not blocking for the major IdPs (Okta, Entra, JumpCloud, OneLogin) when used in their default modes. If a customer needs them, they get added.

Authentication for SCIM calls​

Every SCIM endpoint requires a valid PAT in the Authorization: Bearer ... header. The PAT auth path is the same as for normal API calls (covered on the next page). One difference: SCIM endpoints are exempted from CSRF, because no browser ever calls them directly — only IdPs do, server-to-server.

Audit trail​

Every SCIM operation is audit-logged: who initiated it (the PAT's owner), what they did, when, with what payload. SCIM activity is concentrated and easy to monitor — if something looks wrong, the log shows exactly what the IdP sent.

Key takeaways​

  • SCIM is the standard that lets your IdP push user lifecycle events directly into Dashify.
  • Onboarding, role changes, and offboarding all happen automatically — no human in the loop.
  • Dashify exposes a SCIM 2.0 endpoint at /scim/v2/* authenticated with a Personal Access Token.
  • On termination, the user's account is deactivated, all sessions are revoked, and all PATs are killed instantly.
  • SCIM and SSO are complementary: SSO lets users sign in; SCIM manages whether they can sign in at all.