Unlocking the power of SCIM: streamlining enterprise user management

For whatever reason, technology that helps you support enterprises has a lot of acronyms, from SSO to RBAC to SCIM (and then there’s SIEM, but that’s for another day). Most startups are familiar with SSO and why it’s important but less so with SCIM and user provisioning. 

Across our customers, we’ve seen that SCIM is crucial in selling to larger enterprises with complex IT needs and hundreds to thousands of users that need access. This post will walk through why SCIM is important and the reasons you should consider implementing it: it will help you improve your security posture, automate provisioning and access management, and even simplify your billing process.

SCIM basics and how it works

SCIM stands for System for Cross-Domain Identity Management, and it’s the default protocol for what we in the enterprise world call “directory sync.” Directory sync is a single source of truth for the identity (and characteristics) of employees at an organization, also known as your app’s users. Most enterprises handle this through their existing Identity Provider (IdP) like Okta. 

Directory sync is about more than just who someone is (like their name and email) though. It’s also about what role they occupy in their organization, and what implications that might have for access management in the app you’re building.

Imagine you work at GitHub, and you’re in contract negotiations with Google, trying to close them as a customer. As of 2024, Google has more than 100,000 engineers (conservatively). Each one of these people needs access to different SaaS tools to get their jobs done. Without directory sync, every time Google buys a new piece of software, they (well, their IT admins) would need to manually create accounts for every user that needs access to the software, manually revoke access when those employees leave the company, manually decide which permissions each user should have, and the list goes on.

And lest you think that nobody would actually ever do this, you’d be wrong. Many state of the art SaaS tools today still require IT admins to manually upload CSV files with user names, emails, and roles at a static point in time. At a publicly traded company who shall remain nameless, this is how they handled B2B accounts – they required their customers to upload CSV files uploaded to a web portal. At one particular customer, when the program admin who handled this upload process left, nobody else knew how to do it. Years later, the customer’s new finance head was investigating why they were paying so much for the tool, realized there were a ton of seats that had never been deprovisioned, and ended up canceling the entire contract.

Directory sync exists to solve this problem: instead of doing all of this work manually, your application talks to Google’s IdP and automatically gets the information about their organization. Google’s IdP already knows which users exist and which groups each user belongs to, and an IT admin can simply map those groups to the right permissions in your app. 

The SCIM idea is simple, but implementing it is…not. You can read more in depth about SCIM and what it takes to implement here.

You can group the benefits of SCIM (and there are many) into a few categories:

• Automatic deprovisioning to eliminate security vulnerabilities 
• Pre-provisioning user accounts instead of manually adding and removing users
• Automated access management instead of manually assigning groups and roles
• More accurate, simpler billing instead of manually tracking seats
• Syncing additional user attributes to bring useful external data into your app

Let’s go more in depth on each.

Automatic Deprovisioning

Yes, IT admins having to manually add and remove users from SaaS tools is annoying. But it’s also a major security risk. If an IT admin forgets to remove a user from your tool after they’ve left the company, there can be a period of time where they’re not employed, but still have access to sensitive information. Imagine the case of a disgruntled employee fired for violating the company handbook, who vindictively deletes all of the repositories they worked on because the IT admin didn’t revoke their access to GitHub fast enough (I hope there are backups).

With SCIM, this can’t happen. When a user offboards and gets removed from an organization’s IdP, your app will automatically get notified of that change so you can deprovision their account on your end. End-to-end automation of this process completely eliminates the chance that someone will forget to revoke a user’s access until after they’ve left the company.

This is something that you can only do with SCIM. If you’re just using SSO, there’s no way for your app to be proactively notified when a user needs to be deprovisioned. The IT Admin is at the mercy of the session length to revoke access.

Pre-provisioning user accounts

With SCIM-based directory sync, IT admins (or you) don’t need to manually add user accounts to your application; instead, they sync automatically through your customer’s IdP. The obvious benefit is reducing manual work, but there are some other more subtle (but important) reasons why you’d want to have this.

Solving the discovery problem for new employees

Back to our Google example. They’ve got thousands of software engineers, all of whom you want to be engaged and using GitHub. 

Without SCIM, you’re kind of at the mercy of your sales team (or whoever has a relationship with champions at Google) to continue reminding Google that their engineers should create and use GitHub accounts; after all, they’re already paying for them. With SCIM though, you already know – via the IdP – who each developer is, what their email is, and what groups they’re in. So you can say, send them an email saying something like:

“Hey. Your organization is using GitHub to manage their code. You can get started here.”

For businesses like Figma, Slack, and Notion that heavily rely (or once upon a time, did rely) on product-led growth, improving seat utilization is critical to improving net dollar retention. The more users actively use your product, the better your case is for renewal next year. And if you can show that all of the seats that an enterprise purchased are being actively used, it’s much easier to argue for expansion to more of them. 

This is helpful if you do usage-based billing, too. Even if you don’t charge per seat, the more seats you have filled, the more people there are to do whatever things you charge for. 

Automated access management

If provisioning is the world of having or not having accounts, access management is the world of what permissions those accounts have in your tool. 

Reducing manual work of allocating permissions

Enterprises demand granular access management from modern SaaS tools: you need to have the ability to set different permissions for different users based on what their role is in an organization. You can read more about the different ways of implement access management – role based, and resource based – in our RBAC guide here. This is table stakes for moving upmarket.

If your customers are small enough, you in theory could build granular access management without SCIM, and require your IT admins to manually allocate roles and permissions for each of the users of your tool. But it’s completely unrealistic when you start supporting organizations with hundreds of users, let alone thousands or more. What SCIM allows you to do is automate most of the allocation of roles and permissions. In an organization’s IdP, they’ll have centralized information on what team an employee is on and what groups they might be a part of. For example, a tech lead might be in an IdP’s “admin” group. With SCIM, you can sync those groups directly to your application and apply the appropriate roles and permissions automatically. 

IT admins care about this a lot because at certain sizes, it’s basically impossible to manually allocate roles and permissions. And every time they change (e.g. someone gets promoted), they’d need to manually update that in the tool. 

Reducing access-related security issues

There are potential vulnerabilities involved with access management, too. In the same sense that an employee who no longer works at a company needs to be deprovisioned immediately, someone who changes internal status needs to have their roles and permissions updated immediately too. 

For example, imagine a user of your tool switches teams from engineering to management. Without SCIM, an IT admin would need to manually go into GitHub, remove them from the engineering group, and add them to the management group. In the time before that gets done, the employee has access to engineering resources that they shouldn’t. With SCIM though, this happens immediately and automatically once the IT admin updates the groups in the IdP.

It’s worth mentioning that you can hack SSO to get access management to work, but it will be a terrible experience: you will need to force users to re-authenticate every time there’s a group or role change, which means it won’t solve any of the security issues. SCIM was created specifically to solve this problem and you should use it.

More accurate, simpler billing

This one is pretty straightforward. SCIM gives you a convenient mechanism for accurately measuring how many seats to bill for and when. A common billing-related issue is that a user no longer works at your customer, but their seat wasn’t deprovisioned in your tool, so the customer is still paying for them. For GSuite users among us, the sting of realizing you’ve been paying for an email account for a user that hasn’t worked here in 6 months is probably somewhat familiar. 

Additionally, SCIM allows applications to easily provision “reviewer” roles in collaborative platforms like Loom, Vercel, and Netlify. These "reviewer" roles often do not count towards seat usage, and SCIM ensures accurate billing by only charging for more active roles, such as "owners" and "members."

With SCIM though, users automatically get deprovisioned when they’re removed from the IdP, so you have automated guarantees that your customers aren’t being charged for seats they’re not using.

A good example is Loom. They have 3 roles in the product: default, viewer, and editor. Viewers are free, and editor roles are charged per seat. SCIM allows them to sync these roles from a customer’s IdP and be dead sure exactly how many editors (billed seats) there are, so they can bill their customers accurately. 

Syncing additional user attributes

Some applications require more than just basic groups and roles to provide a nice-to-have feature. Basic examples include profile URLs, preferred name, title, etc. Not having this information wouldn’t fundamentally break your application, but it’s nice to have. So syncing these attributes via SCIM can help you provide that extra mile to your customers.

But there’s another use case where these kinds of attributes are more than just nice-to-have. For spend management platforms like Brex, the title of a user and what team they’re on determines important information within the application, primarily the size of the budget they have access to. 

For workspace management solutions like Tactic, enriching data syncs with information like departments, office locations, and profile pictures allows them to deliver a richer, more personalized in-app experience for its end users. 

This is arguably a core feature within the app, and it depends on information synced via SCIM that goes beyond just groups and identity. 

The only way you can real-time automate this is through SCIM. 

The WorkOS advantage

In the follow-up blog, we'll focus more on the challenges and expected cost of supporting SCIM in-house. With WorkOS, you can drastically cut down on the total cost of ownership with APIs you can integrate in one sprint.

Some of the fastest growing startups like Vercel, Loom, and Webflow use WorkOS Directory Sync to provide seamless user lifecycle management for their enterprise customers.

Get started today