If you have ambitions to sell software to enterprise customers, single sign-on (SSO) and Directory Sync (SCIM) 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 be supported, differences in SAML and SCIM implementations across providers, and the unpredictable nature of custom work to meet each customer’s needs.

Based on interviews with engineering leaders that have built these features in-house, it can take anywhere from a few months to several quarters. 

Development and maintenance costs

Engineering leaders typically structure the product roadmap for both SSO and Directory Sync 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, custom-mapped attributes, and IdP role assignment for Directory Sync.

SSO roadmap

Phase 1

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

Assuming the team will only support Okta – one of the most popular IdPs – the estimated time to launch SSO is about three months with a team of 1-3 engineers. 

Unfortunately, the work does not stop there. Engineers must now coordinate with the customers’ IT admins to ensure smooth onboarding, which often results in lengthy email chains or Slack messages that can last several weeks. Organizations can spend 10-20 hours onboarding each enterprise customer, requiring mixed involvement from engineering and customer success teams. The information that must be exchanged between the two parties includes SSO URL, audience URI, metadata URL, and public certificates.

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 as well as 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

Your engineering team must ensure that the information exchanged in each step is normalized across all IdPs.

In comparison, WorkOS removes this complexity with a single point 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 activate SSO, the onboarding process also changes.

1. Your team likely has separate onboarding documentation for each provider. Instructions can quickly become outdated when providers release any UI changes.
2. Onboarding support is generally handed off to customer success teams to reduce engineering involvement. This lowers the hourly cost but still requires some level of troubleshooting to help IT admins.

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.

Phase 3

The additional complexity in phase three comes from managing SAML certificates, which are crucial for validating the authenticity of SAML assertions and preventing unauthorized access.

Depending on the IdP and the security requirements of the organization, these certificates can expire every one to three years. Prompt renewals are critical to avoid service disruptions, and 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 esoteric IdPs like Shibboleth, Active Directory Federated Services (ADFS), and custom systems used at universities, banks, and government organizations which can take additional quarters to develop. 

Directory Sync roadmap

Directory Sync is a user lifecycle management feature (ULM) that 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 account – are synchronized in real-time with all other applications that support Directory Sync. 

Phase 1

The development and onboarding process for Directory Sync 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 directories, which can lead to invalid events. This is just one example of data fragmentation that your application must solve.

Phase 2

The main theme for the second phase is how data fragmentation worsens as more directories 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?

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 directories, 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 costly and demands continuous support. Engineers must also keep pace with the constantly changing identity and user management landscape, possibly creating more technical debt that can slow down your core product development efforts.

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 long-term growth. 

The hidden complexities and ongoing maintenance of in-house solutions can distract your team from focusing on what truly matters – building and enhancing your core product. Opting for flexible and easy-to-use APIs from WorkOS can help you quickly integrate SSO, SCIM, and other enterprise features to really focus on innovation and growth.