Notifications
Clear all
Topic starter
06/06/2026 2:10 am
TL;DR: SCIM can provision and deactivate users cleanly, but it does not natively carry the authorization context enterprises often need, so vendors use custom schema extensions to pass org, team, and role data alongside identity, according to WorkOS. The governance lesson is that provisioning and authorization must be designed together, or access arrives incomplete and inconsistent.
NHIMG editorial — based on content published by WorkOS: Custom SCIM schemas and how identity provisioning meets authorization
Questions worth separating out
Q: How should security teams design custom SCIM schemas for authorization context?
A: Start with the application’s real authorization model, then expose only the attributes that the product can enforce directly.
Q: What breaks when SCIM treats missing attributes as ambiguous?
A: Ambiguous missing-attribute handling creates entitlement drift.
Q: How do I know if my SCIM schema is too abstract?
A: If administrators must translate a permissions blob into something your application can actually enforce, the schema is too abstract.
Practitioner guidance
- Define authorization primitives first List the exact workspace, team, role, or membership fields your application enforces, then expose only those attributes in the SCIM extension.
- Document remove versus missing semantics Write a clear rule for what happens when an attribute is omitted, explicitly removed, or replaced in a PATCH request.
- Test provider-specific patch shapes Validate your SCIM handler against the request patterns your customers actually use, including non-standard remove payloads and nested attribute paths.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- The exact JSON shapes for core, enterprise, Docker, and Notion-style SCIM payloads.
- Practical guidance on handling add, remove, and replace operations across different IdPs.
- The specific trade-offs between building a direct SCIM contract and using a normalized directory abstraction.
- Examples of how custom attributes surface in WorkOS Directory Sync and AuthKit flows.
👉 Read WorkOS's guide to custom SCIM schemas and authorization context →
Custom SCIM schemas for authorization context: what teams need?
Explore further
06/06/2026 3:41 am
Custom SCIM schemas are really authorization contracts, not just provisioning add-ons. The article makes clear that the point of the extension is to carry org, team, and role context into the target application. That means the operational risk is not incomplete profile data but inconsistent access meaning across systems. In NHI governance terms, the control boundary is the attribute contract itself. Practitioners should treat schema design as part of access design, not as a directory integration detail.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Our research also shows: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: What is the difference between provisioning identity and authorizing access in SCIM?
A: Provisioning moves identity data into an application. Authorizing access determines what that identity can do once it arrives. SCIM custom schemas bridge the two by carrying the authorization context, but the application still has to enforce the meaning of each attribute consistently across create, update, and remove events.
👉 Read our full editorial: Custom SCIM schemas: where provisioning meets authorization
