Firezone explains why it skipped SCIM and built its own directory sync engine

Firezone, whose access model is built around identity-provider groups, has published an engineering writeup on directory sync, the machinery for keeping an organization's users and groups current inside your application. The post argues the job is far harder than the SCIM standard implies, and explains why the company chose to write its own sync engine instead of implementing the protocol. It drew wide discussion on Hacker News.

What directory sync is, and is not

According to Firezone, an organization's directory lives in its identity provider — Entra, Google, Okta and the like — and is made of three parts: users with attributes like name, email and an active-or-suspended status; named groups such as Engineering or Product; and membership records linking users, or other groups, into those groups. Access flows from every group a user belongs to, directly or through nesting.

Directory sync means copying that directory into your app and keeping the copy current as people join, leave or move between teams. Firezone is careful to separate this from single sign-on: OpenID Connect says nothing about how users are brought into an application, and directory sync is exactly that provisioning mechanism rather than the authentication flow.

The post also sketches the data-model challenge. With nested groups, deciding whether a given user belongs to a given group means chasing parent groups through recursive queries. Firezone's answer is to flatten memberships — storing one row per user for every group they belong to, directly or indirectly — so the same question becomes a single lookup.

The SCIM promise

SCIM, the System for Cross-domain Identity Management, is the established standard here. An application exposes a set of REST endpoints covering users and groups, and identity providers push changes to them. The appeal is twofold: push-based updates can land faster than scheduled polling, and in principle one standard API serves every provider.

Where SCIM falls apart

Firezone groups the problems into two kinds. The first is operational. A push-based design requires the receiving app to be up and ready essentially all the time; a few seconds of downtime or overload can mean missing a critical update, and the app has no way to trigger a full resync itself — it must wait for the provider to send the data again.

The second is standardization in name only. SCIM defines the wire format but, in Firezone's telling, says nothing about how endpoints should be called, which lifecycle events they map to, or what data each request carries. Examples from the post:

• Okta can send group-member additions and removals together in one PATCH request, while Entra requires them split and allows only a single member removal per PATCH.
• Entra historically sent the active flag as the string 'False' rather than the SCIM-defined boolean, only later adding a compatibility flag for compliant behavior.
• Okta skips several SCIM capabilities outright, among them bulk operations, POST searches, ServiceProviderConfig and filtering on meta.lastModified.

Deprovisioning diverges most

The inconsistencies are sharpest around deprovisioning, turning off a departing employee's access. Firezone catalogs how differently providers behave:

• Okta depends on ordering: unassign the user before stripping group memberships, or those memberships can survive downstream.
• Entra does not necessarily deactivate a user when a group is removed; access persists if another assigned group still grants it.
• JumpCloud can deprovision through app unbinding, suspension or deletion, not just removal from a provisioning group.
• OneLogin may respond to a user deletion with deletion, suspension, or nothing at all, depending on the app's provisioning settings.

The upshot, Firezone argues, is that the hoped-for single implementation becomes a collection of provider-specific SCIM code paths — effectively one shim per identity provider. Faced with that, the company says it forwent SCIM entirely and built its own sync engine from scratch.

Why it matters

Identity is the foundation of enterprise software, and groups are how most organizations decide who can touch what. SCIM is the default answer for provisioning, yet Firezone's account shows that 'supporting SCIM' in practice means absorbing a distinct set of quirks per provider, with the highest stakes at deprovisioning time, where a missed or mis-ordered event can leave a former employee's access intact. For any team adding enterprise identity features, the post works as a concrete checklist of provider behaviors to test against — and as evidence that adopting the standard may not eliminate the per-provider work it was meant to prevent.