We get a lot of questions about SCIM. I find that lots of answers related to SCIM use too much technical detail. I’ve taken some common questions about SCIM and tried to answer them as simply as I can. I’ve written these answers assuming that my reader has little experience building software. Hopefully that assumption makes these answers more legible to true beginners.

What is SCIM?

SCIM stands for the “system for cross-domain identity management.” SCIM is a standardized set of rules that different software systems follow to communicate with one another about users. We sometimes also use directory sync to describe SCIM.

Usually, we use SCIM in business software to make user management … well … more manageable.

User management isn’t always easy. Companies often use many different software applications. Each software application maintains a list of users that can use the software and access data in the software. This presents a problem to businesses, which need to control their employees’ access to sensitive information. For example, if an employee leaves the company, how can the company make sure that the former employee can’t get back into their email account?

Companies will typically use a centralized software application such as Microsoft Entra, Okta, or OneLogin (among others) to store a single list of employees and rules about their access to software applications. For example, Human Resources leaders will often have access to payroll software, but they won’t generally have access to sales or marketing tools. At SSOReady, we generally call this kind of software that stores information about employees an identity provider.

The company may require the software applications that its employees use – Netsuite, Slack, etc. – to communicate with that centralized identity provider. The software applications will make sure that their lists of users match the list in the identity provider. So when anything changes in the identity provider, the same change takes place in the software applications. For example, if the IT department edits the Ned O’Leary record in the identity provider to say something like not an active employee, Zoom and Google Drive will know not to allow Ned to log in.

In order for this communication to happen, the identity provider and all the different software applications follow the rules laid out in the SCIM protocol. SCIM just makes all this communication easier. Everyone’s “speaking the same language,” in some sense. All the integrations work basically the same way, so nobody has to build complicated custom integrations.

What is SCIM provisioning?

Let’s say a big company hires a new employee called Fred. Before Fred starts work on Monday morning, the company’s IT team sets up his laptop and installs a bunch of apps. An IT admin logs into a centralized identity provider (e.g. Microsoft Entra), and tells the identity provider Fred is a new employee, and he should have access to Zoom.

The identity provider now knows about Fred, so it sends a message off to Zoom: there’s a new employee called Fred that you should know about. So Zoom chooses to create a new user record in its database; it now knows about Fred.

We call this process of creating a new user account for Fred in Zoom “SCIM provisioning.” This process makes life easier for everyone, because the IT admin only has to create a record for Fred in one place. The identity provider sends then sends off requests automatically.

What is SCIM deprovisioning?

Deprovisioning in SCIM is pretty much just the opposite of provisioning. This most commonly happens when an employee leaves a company.

An IT admin will receive word from Human Resources that Fred left the company today, log into the centralized identity provider, and then mark Fred as deactivated.

Then the identity provider will send a bunch of messages off to different software applications, saying something like mark Fred as deactivated.

What are the benefits of SCIM?

SCIM might seem complicated, but it really does make life easier. Without a standardized way to agree on who users are, companies’ IT teams and their software vendors would waste a lot of time manually syncing up their systems.

Because SCIM makes it much easier to manage access to software applications, it has massive security benefits. Companies don’t have to worry as much about the wrong people having access to their software applications – to their data.

If you’re a software vendor, setting up SCIM support will help you sell your software to bigger customers. SCIM is often a requirement for these kinds of companies.

What is a SCIM API?

We can sometimes mean different things when we say “SCIM API.”

If you build software, and you want to support SCIM, you will need part of your software to handle SCIM communication with customers’ identity providers. An identity provider will periodically send requests, and your software needs a way to receive and process those requests. In this scenario, the identity provider has a “SCIM API,” and your software will also have a “SCIM API.” We’re simply talking about the parts of your software and the identity provider that exchange messages.

Sometimes, however, you can use an external service – like SSOReady – that listens for requests from the identity provider for you and simplifies things a bit. In this scenario, you might choose to describe the external service as a “SCIM API.” You will still need to build some software that talks to the external service.

Should I support SCIM?

Simply put, you should probably support SCIM if your customers want you to support SCIM. This will happen if you sell software to security-conscious or large companies; they’ll expect SCIM from their vendors. If you either have a specific customer that needs SCIM or you expect to make most of your money from big companies, you should put SCIM on your product roadmap.

Here’s the good news. In general, if you aren’t sure whether you need SCIM yet, you probably don’t need to worry about it! It’ll come up eventually, but you can focus on other stuff.

If you ever need SCIM, don’t worry. You can set up SCIM with SSOReady really quickly, for free. We’ll be here.

What is a SCIM connector?

When we say “SCIM connector,” we’re usually talking about a piece of software that sits in between a software application and an identity provider. In this sense, SSOReady is an example of a SCIM connector. In our product, we have a concept of a “SCIM Connection,” which just describes a configured relationship between your software and a given identity provider.

Should I use a SCIM connector?

Yeah, probably!

If you’re a strong software developer, you can likely get away with a one-off SCIM integration. For the most part, SCIM makes sense; it’s actually not that complicated.

SCIM can get tricky in practice, though. Identity providers tend to do things differently – sometimes in ways that you wouldn’t expect. You can’t count on the integration you build for one identity provider working very well for another identity provider. So you will likely end up duplicating work if you have a bunch of customers that want SCIM. You’ll also end up maintaining the integrations over time and manually configuring new customers. We find that software developers don’t often enjoy this kind of work.

We generally think you can spend your time on other things, too. You could work on features that make your product outstanding. You could also take a vacation. Using a SCIM connector lets you free up big chunks of time.

What is a SCIM token?

When we say “SCIM token,” we’re usually talking about a bearer token.

When a software application receives SCIM messages from an identity provider, it needs to make sure that the messages actually came from the identity provider – and not from an attacker. If the software application just trusted any message, attackers would find it really easy to assign themselves privileges and do things they really shouldn’t be doing.

We often handle this in SCIM by setting up a secret for every connection between the software application and the identity provider. We just use a randomized string of letters and numbers, something that’d be nearly impossible to guess – kind of like a password.

The identity provider includes this secret – this token – in every message that it sends to the software application. In theory, the software application and the identity provider are the only ones who know the secret. So when the software application receives a message that includes the secret, it knows that the message came from the identity provider.

Because the software application chooses to trust any message accompanied by this secret, it’s very important not to expose the secret accidentally. An attacker that knows the secret can easily pretend to be the identity provider.

What is a ‘group’ in SCIM?

SCIM defines two specific kinds of resources – things that software applications should know about.

One of these is a User. A User is basically what you’d expect. A User in SCIM is a blob of data related to a person. In just about all cases, a User will have an email address, a first name, and a last name, for example, but a User can have any number of characteristics.

The other kind of resource that SCIM defines is called a Group. Most simply, you should think of a Group as a list of people – a list of Users.. In some company’s SCIM implementation, there might be a Group called “Accounting” that just consists of all the people who work in accounting. Groups can also be lists of other Groups, though. To use the previous example, maybe there’s an “Accounts Payable” Group and an “Accounts Receivable” Group that both belong to “Accounting.”

Every company’s Groups will look a little different. Some companies won’t even use Groups in SCIM! You can’t really know until you ask.

What are attributes in SCIM?

Different software applications need SCIM to do different things. SCIM Users and Groups can have any number of different characteristics attached to them.

SCIM handles this by saying that every User and every Group contains an ambiguous blob of information that it calls attributes. An attribute could be basically anything. In theory, you could create a SCIM attribute called “favorite flavor of ice cream” and fill that out for every User. It’s just a piece of data that belongs to a record.

What’s the difference between SAML and SCIM?

We often link SAML and SCIM together, because we use them for related things.

SAML establishes some rules for trading messages between an identity provider and a software application, typically about one user at a time. We mostly use SAML for logging users in via single sign-on (SSO). The identity provider makes a claim about who a user is, and the software application trusts the identity provider’s claim.

SCIM works a little differently. We use SCIM for keeping information about many users in sync across different systems. We use SCIM to make sure software applications all have the same list of users and agree on the attributes associated with those users.

What does SCIM stand for?

The System for Cross-domain Identity Management. It’s kind of jargon-y. The basic idea is that lots of different pieces of software (this is the domain part) need to agree on a bunch of information about users (this is the identity management part), and it’s much easier for them to do so if they’re all communicating in the same way (this is the system part).

Who made SCIM?

A whole bunch of people from different companies worked together to design the SCIM standard. No one person or company made SCIM. If you’re curious, you can find a list of the contributors here.