Build vs. Buy: 5 Questions to Ask When You Need to Offer SSO or Directory Sync

September 30, 2021

Most founders and engineering leaders of SaaS startups are aware of the “build vs. buy” debate: Should our team build non-core components of our software ourselves, or pay another provider and use their already-built solution? The term “non-core” means anything that isn’t directly related to the business’ mission or main product offering — components like payment processing, email marketing systems, and user authentication.

A Google search for “saas build vs buy” reveals dozens of thoughtful articles and forum discussions about whether SaaS founders should build or buy software that supports, but isn’t integral to, their core business. The general consensus of these articles is that software companies should focus on building software that is aligned with their mission.

As your team discusses the build vs. buy tradeoffs of integrating SSO or Directory Sync into your SaaS application, consider the 5 questions below to guide your thinking.

1. Do I want my engineers to become SAML and SSO experts?

Before your engineering team can begin building a custom SAML or SSO solution for your software product, they’ll need to have a solid understanding of how the SAML protocol and SSO authentication flows work. If they are new to using SSO, there is quite a bit of upfront research that needs to be done to ensure that the systems are set up properly. Some of the main pieces of architecture you would need to configure are a SAML controller, a SAML service, and a strategy to correctly authenticate users in your app.

Because getting authentication wrong is such a big security concern, the engineers will also need to understand and mitigate security risks that are inherent to implementing SAML and SSO. Sure, engineers are perfectly capable of learning these things, but you’ll need to consider whether doing so is the best use of their time and skills because there is definitely a learning curve to get up to speed.

2. Should my SaaS company spend time and resources building software that isn’t core to our business?

How you answer this question may depend on the age of your SaaS company and the size of your engineering team. The younger the company and the smaller the team, the more sense it often makes to buy existing software rather than build it in-house.

The reason for this is that there are always opportunity costs in software development. Every line of code your engineers write to recreate an existing service that you are choosing not to buy is a line of code that isn’t written for your core product. Engineers and time are finite resources. Can you realistically pull 2 to 3 (or more) engineers off of product engineering to build and maintain a full-fledged authentication system? This means less time dedicated to building the thing for which your business is trying to have a competitive advantage.

3. Can my engineering team keep up with customer demands for adding new identity providers?

Adding SSO or Directory sync to your application isn’t a one-and-done scenario. There are dozens of identity providers (IdPs) that will need to be integrated with your app so that it can be used by customers with diverse IdPs. Architecturally, that means building out a separate SAML flow for each IdP. This can be a challenge because different IdPs handle the SAML flow in different ways. It’s usually not as simple as just switching out a few API keys.

Even with a dedicated team to build the in-house authentication system, it could take months, even the better part of a year, to integrate enough IdPs such that you can provide SSO or Directory Sync to the majority of potential customers without having to practice “sales-driven development”. This months-long time frame would be even longer if you don’t have engineers working on it full-time. In a WorkOS case study on Webflow, a current WorkOS customer, Webflow estimated that it would have taken their engineering team 3 months to build SSO capabilities into their product offering.

4. Do we have the bandwidth to maintain multiple, custom SSO integrations long-term?

A continuation of the previous question about adding new IdPs, this question centers on the maintenance of all of those various integrations. Each integration will require its own code and tests, which will need to be updated from time to time to avoid code decay. While you won’t usually have to make changes to an integration after it’s in production, you will need to make sure you’ve taken care of any edge cases that pop up and implement a monitoring system for performance and uptime that’s linked to your on-call rotation.

5. Will the engineers building SSO in-house easily find support when they’re blocked?

Despite the ubiquity and importance of authentication in our digital world, comparatively few people understand it thoroughly enough to help troubleshoot building it. 

StackOverflow is the de facto first choice for many developers when it comes to debugging. At the time of this writing, there are 1,598 questions on StackOverflow with the single-sign-on tag that have no answer or no accepted answer. That’s nearly 25% of the total 6,741 questions for the tag overall. Similarly, the saml tag has 702 questions with no answer or no accepted answer out of 3,177 total questions (again, nearly one in four questions).

The relatively low volume of SSO- and SAML-related questions on StackOverflow compared to other technologies and languages is telling. There are comparatively few developers working with SAML and SSO which means the pool of folks available to offer support within the developer community is small.

If you answered “no” to any of these questions…

...your team may not be prepared to build an SSO or SAML integration. You may decide that landing on the “buy” side of the “build vs. buy” discussion is the right move when it comes to adding authentication to your application. If that’s the case, WorkOS may be the right solution. Watch a live recording of a 7-minute SSO integration with WorkOS here!

Start Integrating Today
Create an account to begin adding enterprise-ready features to your application today.
Get Started

This site uses cookies to improve your experience. Please accept the use of cookies on this site. You can review our cookie policy here and our privacy policy here. If you choose to refuse, functionality of this site will be limited.