SailPoint SCIM and SSO, What Each One Does

What Is SCIM and What Does It Do?

SCIM, the System for Cross-domain Identity Management, is an HTTP-based protocol for creating, updating and deleting user accounts and groups across systems, using one shared data model. It lets a source such as an HR system or an IGA platform manage accounts in cloud applications without custom code for each application.

The standard is two documents: RFC 7644, published in September 2015, defines the protocol, and RFC 7643 defines the core schema. SCIM 2.0 is still the version SailPoint documents today, so the standard is stable rather than new. It is not an authentication protocol; it carries identity data, not logins. The place it appears in identity governance is provisioning.

What Is Single Sign-On and How Is It Different?

Single sign-on (SSO) lets a user authenticate once with an identity provider and then access many applications without logging in again. It uses protocols such as SAML, OpenID Connect and WS-Federation. SSO decides whether a person may log in right now; it does not create or remove the account behind the login.

WorkOS describes the timing difference clearly: SSO happens at login, when the user is redirected to the identity provider and returns with a token, while SCIM happens when identity events occur, such as a new hire, a role change or a departure. Where authentication sits in a full identity stack is shown in our IAM architecture diagram.

What Is the Difference Between SCIM and SSO?

SCIM manages the account lifecycle, meaning which accounts exist and what they hold, while SSO manages authentication, meaning who gets in at login. SCIM speaks REST and JSON; SSO speaks SAML or OpenID Connect. They are complementary, not competing, and a SAML versus SCIM comparison is the same comparison.

Search engines show two other phrasings of the same question, “SCIM vs SAML” and “SCIM and SSO together”. They have the same answer: SAML is one SSO protocol, so it sits on the authentication side of the table above.

Do You Need Both SCIM and SSO?

Most enterprises run both, because they cover different gaps. SSO without SCIM leaves orphan accounts: WorkOS notes that a departing employee can be blocked at the SSO login while the application account stays active. SCIM without SSO leaves users with separate passwords. Neither replaces the other, and either can exist alone.

This is where identity governance earns its place. An IGA platform decides who should have an account, records the approval, and removes it on the leaver event, while the identity provider handles login. The full joiner-mover-leaver flow is explained in IAM lifecycle: joiner, mover, leaver, and the three-layer split of governance, access management and privileged access is in IAM vs IGA vs PAM.

How Does SailPoint Use SCIM?

SailPoint uses SCIM in two directions. As a client, SailPoint IdentityIQ (IIQ) and Identity Security Cloud (ISC) connect to applications that expose a SCIM service, load their accounts and provision changes. As a server, IIQ exposes its own SCIM API so other systems can query identity data. The two roles are easy to confuse.

SailPoint’s IdentityIQ SCIM 2.0 connector documentation says the connector targets the SCIM 2.0 standard, and its supported features page lists loading accounts, deleting accounts and adding groups and entitlements, plus support for multiple group object types and API throttling through standard rate-limit headers. The page marks provisioning, password management and access certification as features that depend on SailPoint enabling them for your site, so confirm scope against your release before promising a client full provisioning. In ISC, the SCIM 2.0 SaaS source connects to a SCIM service provider application to load data and provision changes.

The client role is a connector decision, covered in IIQ connectors explained and application onboarding in IIQ. For how the ISC side differs, see SailPoint IIQ vs ISC.

Does SailPoint Support Single Sign-On?

SailPoint does not authenticate your workforce into other applications; it governs who has access. It does support SSO for the SailPoint platform itself: SailPoint’s SaaS documentation describes configuring the platform as a SAML service provider so users sign in through an existing identity provider, and states the platform is never aware of the user’s password.

The service provider configuration page lists the working details. Users need matching identities loaded from the same source as the identity provider. The administrator enters the entity ID, login URLs and a PEM signing certificate from the identity provider, can enable just-in-time account provisioning, then copies the hosted entity ID and SAML URL back to the identity provider. Sessions authenticated through an identity provider expire after 90 days, and SAML single logout is not supported, a gap worth knowing before an audit conversation. Okta, Microsoft Entra ID and Ping Identity play the identity provider role; compare them in SailPoint vs Okta and SailPoint vs Microsoft Entra.

How Do You Call the SailPoint IdentityIQ SCIM API?

To call the IdentityIQ SCIM API, create a dedicated identity with the SCIM Executor capability, authenticate with basic authentication or OAuth client credentials, and send requests to the /scim/v2/ path, for example /scim/v2/Users. If you hit a 401 or 404, check the capability, the authentication method and the exact URL.

1. Create the API identity. Assign the SCIM Executor capability directly to a dedicated identity. A Developer Community reply notes the ReadScimUser right it needs is included by default in SCIMExecutor.
2. Choose the authentication method. Basic authentication or OAuth 2.0 client credentials. In a January 2022 thread on IIQ 8.1, a 401 “User does not have access” cleared once the caller switched to basic authentication and removed the stray authorization header.
3. Call the endpoint. Query the /scim/v2/Users resource under your IdentityIQ context path. A respondent in the same thread reached /identityiq_82/scim/v2/Users in a test system.
4. Read 404s as URL problems first. In an August 2026 thread on IIQ 8.4, a 404 after successful authentication turned out to be an extra slash in the URL.
5. Trace if still failing. The same January thread suggests enabling trace logging on sailpoint.web.Authorizer to see access checks.

One open question from the August 2026 thread is whether the SCIM service needs separate licensing; the thread does not confirm either way, so ask your SailPoint account team. Sources: the Accessing the SCIM API and SCIM API not available in IdentityIQ 8.4 threads. This log-and-trace habit is the one taught in the SailPoint IIQ troubleshooting guide.

What Happens at Offboarding With and Without SCIM?

Without provisioning, offboarding is only partly done: a leaver can be locked out of SSO login while accounts remain active in applications. With SCIM or a SailPoint connector in place, the leaver event disables or deletes the account directly in each application, which closes the orphan-account gap that auditors check first.

The practical point for SailPoint engineers is that the leaver workflow runs through the governance platform, not the identity provider. The lifecycle event fires in SailPoint, which removes access through the connector, and the identity provider then has nothing left to authenticate. That sequence, from lifecycle events in IIQ to the connector call, is the part interviewers probe, so rehearse it as a story with a trigger, a decision and a result.

What Skills Do SCIM and SSO Roles Need?

Employers hiring identity engineers expect protocol literacy alongside platform skill: SAML, OAuth 2.0, OpenID Connect, SCIM and LDAP at concept level, plus the ability to onboard an application and read logs. SailPoint roles lean toward the governance side, so connectors, provisioning and troubleshooting carry more weight than SAML configuration.

Our IAM architect career path guide cites IT Jobs Watch data on identity management architect postings and lists the same protocol set under federation skills, and the IAM career paths page shows where these roles sit. Job availability and pay depend on the employer, location, experience and interview performance; IAM Careers offers placement assistance, not placement guarantees. For interview practice see SailPoint IIQ interview questions.

How Do You Start Learning SCIM, SSO and SailPoint Together?

Start with one working picture: an HR source feeds SailPoint, SailPoint provisions accounts through connectors, and an identity provider signs users in. Learn each layer in that order, then practise the connector step, because application onboarding is where SCIM knowledge becomes SailPoint skill.

The live online SailPoint IIQ training program (45 days, fee ₹25,000, maximum 15 learners per batch, taught live by Oishi, who has 15 years of enterprise IAM experience) covers Application Onboarding (Module 3), Application Rules (Module 6) and SailPoint Troubleshooting (Module 15) inside the 15-module IIQ curriculum. The Identity Security Cloud track is ₹27,000. Classes are live and recorded for LMS access, practice is guided hands-on work with trainer-led demonstrations and step-by-step exercises, and learners receive an IAM Careers certificate of completion. Visit IAM Careers or ask on WhatsApp (+91 93909 81953) for the next batch date.