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.
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.
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.
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.
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.
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.
...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!