The Battle Between Build vs. Buy
Every development team must decide which components to build in-house and which to offload to a 3rd party vendor. This decision is often difficult and hotly debated. After all, most developers chose this career in order to build cool things! Choosing to relinquish that control to buy a solution can seem contrary to their raison d’etre. But developers and their managers are also acutely aware that their time is their single greatest asset. As every company becomes a technology company, leaders are challenged with a scarcity of developer capital, and inefficient usage of their developers. In a recent study conducted by Stripe, C-level executives cite bringing products to market faster, increasing sales, and differentiating products / services vs. competitors as the top 3 areas where developers can have an impact. Of those polled, 96% agree that increasing the productivity of its developers is a high to medium priority.
Historically, companies built their entire technology stacks. But more recently, companies are adopting best-of-breed developer tools which unload pieces of their stack to 3rd-party companies who can do it efficiently and security. So, how should you factor in the identity layer when navigating this decision for your apps and portals?
As consumers, we see countless sign-in screens a day. At first glance, these pages seem pretty simple. There are fields for username and password, a registration page (if the user doesn’t have an account already), a “forget password?” link for forgotten passwords, maybe even social sign-in options for Facebook or Google.
However, when building out this page, you quickly realize there’s a lot more under the hood than it appears. First, you’ll need to asses your developers’ knowledge in this area, and clarify the scope of your project. Then, consider the following questions:
- Do your developers understand open standards such as OpenID Connect, and OAuth 2.0?
- Which authentication options will you need to provide other than username and password? Social authentication? Others?
- Will you need to federate with an existing identity provider or an outside directory like Active Directory or LDAP?
- Should you provide your users with multiple authentication options?
- Will you require strong (multi-factor) authentication from users? If so, which factors, and what's your method for enroling them?
- What information will you require if a user forgets their password or second factor? Will you lock them out if they’ve tried too many times? How will you allow them to recover their account?
- How do you plan to manage passwords? What about managing sessions?
This list can get longer, and “scope creep” can happen as you discover corner cases. Fulfilling these requirements can be tedious and difficult for your developers. Getting it right can mean dedicating development resources to these challenges during the initial build, then continuing on as identity requirements evolve.
Sign-in pages are often the most targeted component of your application. In addition to UX threats, users are susceptible to phishing and social engineering attacks. And, as we saw in the prior section, developer time may be required to build out complex authentication, authorization, and user management workflows for your app. Getting it right requires time and expertise. The Open Web Application Security Project (OWASP) foundation puts out an annual top 10 list of the most critical security risks to web applications. Every year, identity-related risks appear on this list. Risks like broken authentication, broken access control, and insufficient logging and monitoring are directly related to the identity layer of your app. When making your build vs. buy decision, investigate the following:
- How experienced and up-to-date is your team on security and DevSecOps?
- What are your processes for ensuring that your code and libraries are constantly monitored, maintained, and patched?
- How will you stay on top of the latest cryptographic trends?
- Which organizational controls and secure engineering practices exist in your engineering teams?
- Where do network and application security responsibilities live within your organization?
- Do you open up your code for penetration testing?
- What tools do you use for security analytics?
Security has become a board-level discussion with the number and magnitude of reported breaches increasing annually. Companies must consider the customer information, including PII, they are holding, and how they are securing that data.
The need to be vigilant about attack vectors, plus the custom code needed for complex identity workflows, requires robust resources. Companies sometimes underestimate the experience, quality, and sheer number of developer resources required for these projects. Some companies make the sacrifices to "do it right" and slip their deadlines. Others don’t have that luxury and opt to add developers to the project, or prioritize only certain features. Most companies choose the latter. As a result, Stripe’s survey of 1,000 developers found that the average developer spends over 15 hours per week fixing technical debt and bad code.
When it comes to the build vs. buy identity decision, development leaders should ask themselves the following questions:
- Is identity our organization’s core value proposition?
- How many of our developers are skilled in identity? If we don’t have enough, how can we attract and retain more?
- If we divert a developer from another team, what are the implications on other priorities?
- What is the impact of missing a product launch deadline?
Build vs. buy can be a contentious discussion, and we’ve only scratched the surface of the serious considerations going into the decision. For a deeper discussion and more specifics, join our live Webinar on October 10th to learn how companies make the business case for build vs. buy, and the benefits of a pre-built identity microservice.
Can’t make the webinar? Download our whitepaper, Build vs. Buy: Key considerations and the advantages of a pre-built identity solution now for more details.