Build vs buy part I: complexities of building SSO and SCIM in-house

If you have ambitions to sell software to enterprise customers, SSO and SCIM provisioning are likely non-negotiable features. This creates a familiar dilemma for engineering leaders: to build in-house, or buy.

Quantifying the true cost of a homegrown solution can be challenging. There are countless identity providers (IdPs) to support, differences in SAML and SCIM implementations across providers, and the unpredictable nature of custom work to meet each customer’s needs.

Based on customer data, third-party research, and interviews with engineering leaders, this article provides a comprehensive overview of why using WorkOS is a substantially better financial decision than building SSO and SCIM from scratch. 

The benefits of using WorkOS are:

1. Reduction in development and maintenance costs 
2. Faster and more polished onboarding experience for enterprise customers
3. Accelerated time to market for enterprise plans, leading to quicker path to revenue

Development and Maintenance Cost of SSO and SCIM

Engineering leaders typically structure the product roadmap for both SSO and SCIM in three phases: 

• Phase 1: support for a single IdP
• Phase 2: support for core IdPs (Okta, Entra ID, Google Workspace)
• Phase 3: support for specialized IdPs (custom systems, ADFS, Shibboleth, and more)

Identifying the scope of work and the development time required for each stage will be important in measuring the true cost of a homegrown solution.

However, an important distinction is that these roadmaps focus on the minimum work required to support more IdPs as you onboard more enterprise customers. These do not take into consideration additional work required to enhance the core feature set, such as domain verification and JIT provisioning for SSO and custom-mapped attributes and IdP role assignment for SCIM.

SSO roadmap

Phase 1

The first iteration for SSO focuses on developing the underlying infrastructure. This includes aggregating customer requirements, integrating open source libraries, modifying the existing login flow to be compatible with SSO, and other reliability and security tests. 

For most early-stage startups pursuing their first enterprise customers, the engineering team driving this work will consist of 1-3 people. Assuming the team will only support Okta, one of the most popular IdPs, the estimated time to launch SSO is about 3 months. 

"We considered building SSO in-house but abandoned the idea when we realized it would take a team of two engineers several months to support one IdP integration from scratch."

Jeff Lloyd, Tech Lead, Warp

Unfortunately, the work does not stop here. Engineers must now coordinate with the customers’ IT admins to ensure smooth onboarding, which often results in lengthy email chains that can last several weeks. The information that must be exchanged between the two parties includes SSO URL, audience URI, metadata URL, and public certificates.

While this exchange might sound simple, the onboarding process for one enterprise customer can take 10-20 hours, requiring mixed involvement from engineering and customer success teams. Delays are primarily caused by having to retrieve configuration values, test the SSO flow, and potentially debug configuration issues. 

One of the many draws of WorkOS is the Admin Portal, which provides a self-serve onboarding flow for IT admins. WorkOS regularly updates the Admin Portal as identity providers change their UI, requiring minimal engineering involvement and ensuring a successful setup every time. The need for the Admin Portal will become more pronounced in Phase 2. 

Phase 2

As the solution matures, you must support more IdPs and find ways to make the onboarding process as efficient as possible.

A common pitfall at this stage is underestimating the work needed to support multiple providers. While Okta will likely cover about 40% of IdP requests, supporting Entra ID (Azure) and Google Workspace becomes essential as your customer base grows. The challenge lies in dealing with different interpretations of the SAML spec across providers and XML nuances and vulnerabilities, even though SAML is designed to be a standardized protocol.

The illustration above is an example of a generic SAML authentication flow. Conceptually, the process is straightforward but nuanced across providers. As a result, your engineering team must ensure that the information exchanged in each step is normalized across all IdPs.

• Google Workspace
• Okta
• Entra ID

In comparison, WorkOS removes this complexity with a single point of integration, allowing you to support any IdP while retaining the same auth stack your customers use to log in to you app.

Generally, rolling out additional IdP support is just a fraction of the overall maintenance work. This also includes responding to security incidents, fixing bugs, and managing SAML certificate renewals. 

As more customers set up SSO, the onboarding process also goes through a few changes.

1. Your team likely has separate onboarding documentation for each provider. However, instructions can quickly become outdated when providers roll out any UI updates.
2. Onboarding support is generally handed off to customer success teams to lower the hourly cost. However, engineering involvement is still required during troubleshooting.

Depending on the level of enterprise growth, onboarding alone can become a significant time sink, consuming hundreds to thousands of engineering and support hours each year.

"What sold WorkOS was the Admin Portal. Our UI gives customers a link; they go to the Admin Portal, complete onboarding steps at their leisure, and never have to talk to us, making the onboarding process a breeze."

Chris Pickett, Staff Engineer, Prefect

Phase 3

The additional complexity in phase 3 comes from managing SAML certificates, which are crucial for validating the authenticity of SAML payloads and preventing unauthorized access. Depending on the IdP and the security requirements of the organization, these certificates can expire between 1 to 10 years. Prompt renewals are critical and to avoid service disruptions, the developer/support teams must coordinate closely with the IT admins for a phased rollout or replacement during a maintenance window.

Additionally, it is not too uncommon to see enterprises requesting support for specialized IdPs like Shibboleth, Active Directory Federated Services (ADFS), and custom systems used at universities, banks, and government organizations. Supporting these specialized providers can take 1-2 quarters.

SCIM Roadmap

Directory Sync (SCIM) is a user lifecycle management (ULM) and automated access control feature that is commonly implemented using the SCIM protocol. It allows IT admins to centrally provision and deprovision users from their directory provider. For example, when changes are made in the customer’s directory, these updates—whether adding new users, changing roles, or terminating accounts—are synchronized in real-time with all other applications that support SCIM. 

Phase 1

The development and onboarding process for SCIM is not just complex; it's intricate and requires a detailed understanding of various directory providers. It's generally more complex and time-consuming than SSO for a few reasons:

1. SCIM, the SAML equivalent for Directory Sync, was developed much later. Very few open-source libraries provide even the basic scaffolding needed to build it in-house.
2. The data that flows between a directory and your application is more variable. Setting up user CRUD endpoints for attributes like name, email, roles, and custom fields requires more work.
3. A user's email address is critical information needed for a successful SCIM integration. Unfortunately, this field is not mandatory in many providers, which can lead to invalid events. This is just one example of data fragmentation that your application must solve.

"There are a ton of libraries like Passport.js that provide you some reference points for SSO, but no one has solved the story of SCIM — and the ability to integrate with multiple providers. That is, until we came across WorkOS."

Jarel Fryer, Engineering Manager, Chromatic

Phase 2

The main theme for the second phase is how data fragmentation worsens as more providers are supported. Below are some examples that show inconsistencies across providers:

• Onboarding fragmentation – differences across IdPs mean you need custom documentation and flows for each during onboarding
• Differences in IdP implementation – IdPs interpret SCIM differently, and your system will require trees of logic to handle each unique case
• Triage and resolution fragmentation – when your directory gets into a bad state, you need to help your users triage (especially if it’s an IdP issue)
• Correctness – parallel and duplicate requests coming in from IdPs
• Scale – can your application handle large blocks of concurrent requests on initial synchronization from an IdP?

For a more detailed breakdown of the fragmentation challenges for SCIM, refer to this blog.

Phase 3

As the solution matures and caters to organizations with tens of thousands of employees, latency optimizations and maintaining availability become bigger priorities. This is additional work that is piled on top of maintenance, normalizing fragmentations, developing support for more directory providers, and keeping documentation up-to-date.

For example, an application typically receives a burst of requests when the integration is first set up (user onboarding), followed by a smaller set of ad-hoc updates (new hiring classes, RIFs, re-orgs). The SCIM RFC also specifies that the IdP pushes data to your app, not the other way around, which means faulty implementation can flood your system with a million requests in a matter of minutes, causing a complete system failure. Worse, most IdPs do not allow rate limits, forcing the application to be highly available and capable of gracefully handling a surge of requests.

Trade-offs of building in-house

As the roadmaps above show, building and maintaining an in-house solution for SSO and SCIM is expensive and requires constant support from a dedicated team. Engineers need to keep up with the fast-changing identity and user management landscape, which can lead to technical debt and slow down your core product development.

For early-stage startups, time to market is crucial. The initial months spent on research and development can create opportunities for competitors to catch up or even surpass your core product’s capabilities. Multi-year enterprise contracts are also difficult to dislodge, which means any delays that are introduced can significantly impact your ARR and long-term growth. 

By choosing WorkOS, you can avoid these risks and accelerate your journey to becoming Enterprise Ready, ensuring a smoother, faster, and more polished onboarding experience for your customers.

In Part 2 of this series, we'll dive into a detailed ROI analysis, showing how choosing WorkOS over an in-house solution can lead to a 1,954% ROI over three years. By making an informed decision today, you can save time, cut costs, and stay ahead of the competition.