Building vs. Buying an Authentication Solution?

All development and operations teams regularly face building vs buy decisions when it comes to deploying infrastructure. With the prevalence of open source Kubernetes Gateways like Emissary-Ingress, or the prevalence of open source proxies like Envoy, it is natural that organizations will ask the question - should I build on top of these open source projects or buy functionality from third-party vendors. In the case of authentication (Oauth) for API Gateways, it is almost always better to purchase from a vendor, unless there is a business justification to scale up and maintain a long term authentication project.

To assess the right choice, here are some criteria you can use to evaluate whether you want to build your own OAuth service or purchase a subscription to a pre-built application such as Edge Stack API Gateway.

Authentication Implementation: Build Scenarios

OAuth is a big and complicated topic. However, there are some scenarios where building your own might make sense.

You are at the extremes of authentication complexity.

The first scenario involves the complexity of the OAuth needed. At both ends of the complexity spectrum, the very simple or the very complex, building a bespoke solution is probably the right choice. Some integrations that just require username and password can be accomplished with open source tools in a short period of time. Maintenance for these types of applications should be simple, and in the case of IT team turnover, new developers should be able to decode the work.

At the other end of the spectrum are the extremely complex use cases. In these cases, authentication might be a fully integrated, critical component of the infrastructure that justifies the work, effort and commitment for a custom solution. In these cases, this infrastructure component is unique to your business. It isn't what Amazon CTO Werner Vogels calls "undifferentiated heavy lifting". Authentication is one of your key differentiators to the user experience.

You are a major open source supporter and contributor across the enterprise.

The second scenario where building a solution occurs in enterprises that have a deep conviction to remain open source, and only build extensions on top of open source platforms. In this case, the enterprise has made some kind of business calculus to avoid vendor licensing fees. It has determined that between open source software, development efforts in low-cost countries, and through sheer scale, very few projects are beyond the scope of work that they can achieve internally. These types of organisations are few and far between, but Ambassador Labs comes across them usually as they are also avid supporters and contributors of open source.

Your application has a low-security risk.

Of course, a low-security risk application might not need significant authentication. Purchasing from a vendor provides knowledge of security tests and code specifically developed to prevent authentication attacks. Using Kubernetes Custom Resource Definitions is probably not essential to maintain consistency in the authentication process, or else there are other more manual, but sufficient ways to do this. With a low-security risk for the application, it is also likely that all microservices can have the same access controls. Mostly, you have an application where security is not that important, and hence everyday vanilla security works. The ongoing cost, required SLA, and potential blast radius of addressing a high priority security or integration maintenance issue just isn't there. So why bother to spend time building anything complex, and buying doesn't make much sense either.

Authentication: The Buy Argument

The buy argument will generally appeal to more enterprises and smaller development shops. Here are some of the vital buy arguments.

Your list of requirements is more than just username and password.

Matching your required product capabilities with those supplied by existing products like Edge Stack is a good starting point. Most OAuth implementations are relatively generic. In the case of unique requirements, checking with the vendor and determining the vendor roadmap can quickly establish technical fit. Edge Stack API Gateway currently supports a wide range of authentication-related use cases. These include:

1. Secure Single Sign-On via integration with an existing Identity Provider over OpenID Connect/OAuth2
2. Authenticating JWT requests
3. Fine-grained access control, e.g., specifying which microservices are subject to which specific authentication and access policies.
4. Multi-domain authentication, where a single credential enables access to multiple different domains.
5. Secure logout, where the logout operation doesn't just delete the session cookie, but does full session invalidation all the way to the Identity Provider.

Edge Stack provides all these capabilities in a way to minimize operational cost and friction:

• Enterprise support, backed by independent third-party penetration tests
• Managed through Kubernetes Custom Resource Definitions, enabling different teams to independently manage policies
• Integrated credential caching for maximum scalability and performance

Your requirements list might not be as long, but each item on the list should be considered. There are many shortcuts to authentication, but most are not great.

Time to market is important.

Provided the vendor has done their job well, the time to market should be almost an order of magnitude faster to purchase an off the shelf solution vs attempting to build it. As the delta narrows for make vs buy implementation times, building can be more advantageous. Much of this has to do with how well the vendor has built out their application. Edge Stack API Gateway can be up running in minutes providing OAuth services. Building authentication services can take 200+ days, depending on the required capabilities.

Your team is constrained to deliver projects that drive top-line value.

Vendors have experts in the area they have built. You have experts delivering your product or service. Engineers certainly could learn what the vendor has done, but at what cost to other more critical projects. In the case of OAuth, unless this were somehow a mission-critical part of your business, the vendor's expertise would allow you to focus on what makes your business tick.

To successfully build OAuth, Ambassador Labs estimates your team would need to be experts in the three main RFCs that govern OAuth:

• OAuth 2.0 Framework (https://tools.ietf.org/html/rfc6749) RFC 6749
• Bearer Tokens (https://tools.ietf.org/html/rfc6750) RFC 6750
• Threat Model and Security Considerations (https://tools.ietf.org/html/rfc6819) RFC 6819

Setting aside an engineer to study these documents, then actually building is going to take time. Our estimate is 200+days, plus 40 days per year maintenance. This time just allows for basic authentication and does not necessarily allow for time to keep up with new trends, technologies and potential integrations with other vendors to easily extend capabilities.

You have concerns that the project will be staffed for several years.

Deciding to build OAuth has a high upfront cost in terms of engineering time to develop it, combined with a long tail of costs to support the code. This investment may never pay off. Worse, what is more likely is that the homegrown solutions are poorly documented. With almost certain turnover, the engineer who originally built the solution leaves the company or the project, and engineering management is left with an unsupported application with mounting technical debt.

For larger organizations with enough engineers, enough operating discipline, and a long term strategic commitment to build on top of open source, longevity may be less of an issue. For most organisations, longevity is a significant issue that makes the initial high investment in building your own application even higher.

Security risks are average or higher.

Different parts of the infrastructure stack have different elements of risk. OAuth is an area of high risk to the security of an application if not done correctly. Organisations might have the engineering expertise to build OAuth based on their perceived requirements. What an organisation won't have is collective expertise of implementing OAuth across thousands of organizations. Vendor skill level from this collective experience makes vendor-driven security solutions almost always superior to handcrafted, internal development projects. The threat vectors are diverse. The more you see, the more you can secure. While some projects might pass all the above tests for developing internally vs using a vendor, the risk element almost always points towards a vendor solution. Of course, in some cases, security isn't as big a factor. But this is the rare exception.

Conclusion

Build vs. buy discussions for OAuth are common. Unless an organisation is dealing with a low risk, simple OAuth solution and they have the engineering resources to fully commit to a long term effort to build and maintain authentication capabilities, in almost all cases, working with an external vendor will make more sense financially, both from a risk perspective and in regards to opportunity cost.

Thousands of organisations have successfully deployed Ambassador's open source API Gateway, and hundreds of customers are using Edge Stack and the related OAuth authentication functionality. The Ambassador team has helped many teams and organizations create a business case that demonstrates why building bespoke authentication services is not a best practice. Working together with a trusted partner with expertise in the edge and API security ecosystem rapidly provides a positive return on investment for most organisations.