Category: User Provisioning

SCIM Resource

Also known as: SCIM Object

Simply put

In the System for Cross-domain Identity Management (SCIM) standard, a resource is any entity that a service provider manages and exposes for automated identity provisioning, such as a user account or a group. Resources are the building blocks that let one system create, update, and remove identity information in another system in a standardized way. The SCIM standard defines common resource types like User and Group, each with its own set of attributes.

Formal definition

In SCIM 2.0, a Resource is the base object type from which all SCIM objects are derived. According to the specification, every SCIM object inherits common attributes including id, externalId, and meta, and the standard defines core resource types, most notably User and Group, that are exposed through corresponding endpoints (typically /Users and /Groups). A SCIM Resource represents an entity offered by a service provider and is the unit of identity data exchanged during cross-domain provisioning operations. Note that SCIM addresses identity lifecycle and provisioning concerns (creating, reading, updating, and deleting identity records) rather than runtime authentication or authorization enforcement; the specific resource types, extension schemas, and supported attributes may vary depending on the service provider's SCIM implementation and schema configuration.

Why it matters

SCIM Resources are the standardized unit of identity data that make automated cross-domain provisioning possible. Without a common resource model, every integration between an identity provider and a downstream application would require bespoke, one-off connectors to translate user and group data. By defining resource types such as User and Group with a shared set of common attributes (id, externalId, meta), SCIM lets organizations provision, update, and deprovision accounts across many service providers using a consistent interface, which reduces integration effort and the risk of drift between systems.

The governance value is most visible at the edges of the identity lifecycle. When a SCIM Resource for a departing employee is deleted or deactivated in a downstream system through automated deprovisioning, orphaned accounts, one of the more persistent access-hygiene problems, are less likely to linger. Conversely, inconsistent or incomplete resource schemas across service providers can undermine that benefit, because attributes supported in one implementation may not exist or map cleanly in another.

It is important to scope the value correctly: SCIM Resources address identity lifecycle and provisioning (creating, reading, updating, and deleting identity records), not runtime authentication or authorization enforcement. A well-provisioned User resource says nothing on its own about how that user is authenticated at login or what a policy decision point will permit at access time. Treating SCIM as a provisioning mechanism, rather than as an access-control model, keeps these concerns properly separated.

Who it's relevant to

IAM engineers and integration architects

Engineers building or maintaining provisioning connectors work directly with SCIM Resources when mapping source identity attributes to the User and Group resource types exposed at a service provider's /Users and /Groups endpoints. Understanding the base resource model, and the fact that supported attributes and extension schemas vary by implementation, is essential for reliable attribute mapping and troubleshooting.

Identity governance and administration leads

IGA teams rely on SCIM Resources as the vehicle for automated provisioning and deprovisioning across connected systems. Because the resource is the unit of identity data exchanged during lifecycle operations, governance leads should confirm that create, update, and delete flows behave consistently so that joiner, mover, and leaver events translate into accurate downstream account state.

System administrators

Administrators operating downstream applications configure how incoming SCIM Resources are received, matched, and persisted, including how User and Group objects and their attributes map to local records. Awareness that a service provider's SCIM implementation determines the supported resource types and attributes helps administrators set correct expectations for what will and will not synchronize.

Compliance and audit officers

Auditors reviewing access hygiene benefit from understanding SCIM Resources because automated provisioning and deprovisioning of these objects supports timely removal of access and reduces orphaned accounts. Officers should note that SCIM covers identity lifecycle records rather than runtime authentication or authorization, so evidence of provisioning activity is one input to access reviews, not a complete picture of enforced access.

Inside SCIM Resource

Core Attributes

The base set of attributes common to all SCIM resources, including id (a service-provider-assigned unique identifier), externalId (a client-assigned identifier), and the meta complex attribute. In most implementations id is read-only and generated by the service provider.

Schemas Attribute

A multi-valued attribute listing the URIs of the schemas that define the resource, such as the core User or Group schema plus any extension schemas. It declares which attribute definitions apply to a given resource representation.

Meta Attribute

A complex attribute containing resource metadata, typically including resourceType, created and lastModified timestamps, a location URI, and version (an entity-tag used for optimistic concurrency). Specific fields present depend on the service provider.

Resource Type

The classification of the resource, most commonly User or Group in SCIM 2.0, though service providers may expose additional resource types via their ResourceType and Schema endpoints.

Schema Extensions

Additional attribute sets layered onto a core resource, such as the Enterprise User extension for attributes like employeeNumber, department, or manager. Custom extensions vary by deployment.

JSON Representation

SCIM resources are typically exchanged as JSON documents over HTTP, where attribute names map to defined schema elements. The concrete attribute set present depends on the resource type and configured extensions.

Common questions

Answers to the questions practitioners most commonly ask about SCIM Resource.

Does a SCIM Resource handle authentication of the user it represents?

No. A SCIM Resource is a provisioning and identity-lifecycle construct: it represents a managed object such as a User or Group and its attributes, and SCIM is used to create, read, update, and deactivate that object across systems. Authentication, verifying who a principal is at runtime, is a separate concern handled by protocols such as OpenID Connect or SAML. Provisioning a SCIM User Resource does not by itself authenticate anyone; it typically establishes the account and attributes that an authentication flow may later reference.

Is a SCIM Resource the same thing as an LDAP directory entry?

Not exactly, though they can represent overlapping data. A SCIM Resource is a JSON-based object defined by the SCIM schema model and manipulated over a RESTful API, whereas an LDAP entry lives in a directory and is accessed via the LDAP protocol with its own hierarchical DN-based structure. In many deployments a SCIM service provider is backed by an underlying directory, so a SCIM User Resource may map to an LDAP entry, but the two are distinct representations and the mapping depends on configuration.

How do I uniquely reference a SCIM Resource across systems?

SCIM typically distinguishes between the service provider's assigned 'id' (a stable, server-generated identifier for the Resource) and the 'externalId' (an identifier supplied by the provisioning client to correlate the Resource with its own record). In most deployments you use 'id' for direct API operations against the service provider and 'externalId' to reconcile that Resource with the source system. Exact uniqueness guarantees and mutability depend on the service provider's implementation, so confirm behavior against the specific vendor.

How should I update only certain attributes of a SCIM Resource without overwriting the rest?

SCIM generally supports both PUT, which replaces the full Resource representation, and PATCH, which applies targeted attribute-level modifications. In most cases you use PATCH for partial updates such as changing a single attribute or adding a group membership, to avoid unintentionally clearing attributes the client did not send. Support for PATCH operations and the precise path syntax can vary by service provider, so validate which operations are honored before relying on them.

How are multi-valued or complex attributes like emails and group memberships represented on a SCIM Resource?

SCIM models complex attributes as structured objects and multi-valued attributes as arrays of such objects, often with sub-attributes like 'type', 'value', and 'primary'. For example, a User Resource may carry multiple email entries distinguished by type. Membership relationships are typically expressed through Group Resources or membership attributes depending on the schema. How these are surfaced, and which are read-only versus writable, depends on the service provider's schema definition and configuration.

How do I discover which attributes and extensions a given SCIM Resource supports?

SCIM defines discovery endpoints, commonly for schemas, resource types, and service provider configuration, that let a client inspect which Resource types, attributes, extensions, and operations a service provider exposes. Consulting these rather than assuming a fixed attribute set is advisable, since supported attributes, required fields, mutability, and enterprise extensions vary by deployment. This is out of scope of the Resource object itself but is the mechanism used to interpret it correctly.

Common misconceptions

A SCIM resource is a form of authentication or a credential.

SCIM is a provisioning and identity administration mechanism (an IGA concern) used to create, read, update, and deactivate resources such as users and groups. It does not authenticate principals at runtime, and a SCIM User resource is not a credential or token.

Every SCIM resource carries the same fixed set of attributes across all systems.

Beyond the core attributes defined by the schemas, the actual attributes present depend on the resource type, the schema extensions in use, and the specific service provider. Behavior and supported attributes vary by deployment and can be discovered via the service provider's schema-related endpoints.

The externalId and id fields are interchangeable identifiers.

In most implementations id is assigned and owned by the service provider and is typically read-only, while externalId is assigned by the client to correlate the resource with its own records. They serve different purposes and are managed by different parties.

Best practices

Use externalId to maintain a stable correlation between your source-of-truth records and the service provider's assigned id, rather than relying on mutable attributes like userName or email for matching.

Consult the service provider's ResourceType and Schema endpoints to determine which resource types, core attributes, and extensions are actually supported before building provisioning logic, since support varies by vendor and deployment.

Leverage the meta.version entity-tag for optimistic concurrency control when updating resources to avoid overwriting concurrent changes, where the service provider supports it.

Prefer PATCH operations for partial updates where supported, and be explicit about which schemas and extension URIs you include so the service provider interprets the resource representation correctly.

Treat SCIM resource management as an identity administration and lifecycle activity distinct from runtime access enforcement; keep provisioning, deprovisioning, and attribute synchronization decoupled from authentication and authorization decisions.

Validate that required core attributes and any mandatory extension attributes are populated per the applicable schema before submitting a resource, and handle the possibility that read-only attributes returned by the provider differ from what was sent.