Notifications
Clear all
Topic starter
06/06/2026 1:50 am
TL;DR: SCIM schema discovery lets an identity provider learn what a server supports through ServiceProviderConfig, ResourceTypes, and Schemas, but real-world IdP behaviour varies sharply across Okta and Entra, according to WorkOS. Provisioning teams cannot treat SCIM as a uniform contract because discovery order, extension handling, and feature support differ by client and server.
NHIMG editorial — based on content published by WorkOS: How does SCIM Schema Discovery work
Questions worth separating out
Q: How should security teams validate SCIM integrations across different identity providers?
A: They should test the full discovery sequence, not just user creation.
Q: Why do SCIM integrations fail even when the protocol is standardised?
A: They fail because the protocol is standard, but the implementations are not.
Q: What breaks when SCIM schema extensions are not discovered correctly?
A: The integration may still provision core users and groups, but the enterprise attributes that drive reporting and access logic can be lost.
Practitioner guidance
- Inventory IdP discovery behaviour before go-live Document how each directory client consumes ServiceProviderConfig, ResourceTypes, and Schemas.
- Test extension attribute fidelity end to end Validate that enterprise fields such as department, costCenter, and manager are discovered, mapped, written, and retained after updates.
- Version SCIM integrations by client behaviour Maintain separate test cases for each IdP and application type, because discovery order and schema retrieval can differ materially.
What's in the full article
WorkOS's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step request and response examples for each discovery endpoint, including the exact JSON fields clients read.
- Vendor-specific behaviour notes for Okta, Entra, SailPoint, and other directory clients that shape implementation choices.
- Full schema payload examples for core and enterprise user attributes, including extension handling and field mapping.
- Implementation guidance on when mature clients can skip discovery steps and when they should not.
👉 Read WorkOS's guide to SCIM schema discovery and discovery endpoints →
SCIM discovery endpoints: what identity teams need to plan for?
Explore further
06/06/2026 3:11 am
SCIM discovery is a governance dependency, not just an implementation detail. Identity teams often treat provisioning as a transport problem, but the article shows that a SCIM integration first has to negotiate capabilities, resources, and schema extensions. That means the control boundary is wider than the API request itself. When discovery varies by IdP, provisioning behaviour becomes tenant-specific rather than standardised, which creates governance drift. The practitioner conclusion is that SCIM should be validated as a lifecycle control, not assumed as a universal connector.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly provisioning blind spots become governance blind spots.
A question worth separating out:
Q: How do you know whether SCIM is actually supporting lifecycle governance?
A: You know it is working when the right attributes, group memberships, and deprovisioning actions persist across the full joiner-mover-leaver flow. A successful create call is not enough. The integration must also preserve extension data, support updates, and behave consistently across the specific identity providers you use.
👉 Read our full editorial: SCIM schema discovery shows why IdP variance shapes provisioning
