Should You Roll Your Own RBAC Authorization?

Building a secure application is a top priority for any developer, and managing permissions or authorization is a key component in achieving that. One of the most critical decisions that developers face when building an application is whether to build their own security features or buy them from a third-party provider - a question that commonly sparks some lively debates.

In the past few years, a solid consensus has been established that developers should not roll their own authentication, and numerous content pieces [1] [2] [3] have been created on the subject. This type of shift isn’t limited to the security space - building your own payment infrastructure instead of using solutions like Stripe has been considered absurd for a while now.

With Authorization, the question of build vs. buy has not been debated as much, as full-stack Authz solutions are only now beginning to emerge. This blog aims to point out the main challenges you will face in building your own authorization layer, to help you consider this decision.

Build Vs. Buy in a nutshell

The decision between building or buying a security component can be a difficult one. Building your own authorization system gives you complete control over the code, and you can customize it to meet the specific needs of your application. However, building an authorization system from scratch can be a time-consuming and resource-intensive process. 

Here are some questions you should consider before deciding to roll your own authorization layer:

Will your solution keep your data protected?

THE number one question you should ask yourself when deciding whether to build your own authorization is: “Can I build a solution that is robust enough to keep my data secure”. While you may think that building your own authorization system gives you complete control over security, making a mistake can pose enormous potential security risks - putting your application, if not your whole organization, at risk. Building a secure authorization system requires expertise in best practices, as well as in-depth knowledge of the authorization field - which may not be readily available in-house.

Who creates, implements, and maintains your authorization?

Another key challenge of building your own security features is ensuring that the knowledge of how the component works is not solely dependent on one person. If only one person knows how the system works, it can become a bottleneck for the entire development team, as well as your end users. This is especially true when that person leaves the company, goes on vacation, or simply becomes unavailable for an extended period of time. 

It’s also important to note that authorization doesn’t end at the point of implementation - 

Depending on the expertise of a single developer (Or even a designated team of developers, if your organization has the workforce to spare) to create, implement, and maintain the authorization layer can easily result in an unending stream of feature requests you might not be able to handle.

A quick review of large-scale companies that persisted in building authorization on their own shows dedicated AuthZ dev teams growing to an average of 6 engineers (an average cost of $900,000 per year).

Who interacts with your authorization? Who writes the code? 

One important best practice to consider when adopting an authorization solution is to manage the authorization policy as code. In short, when managed as code, policies can be managed using the same tools and processes used to manage and deploy software. This makes it easier to track changes to policies over time, roll back changes if necessary, and in general, enjoy the well-thought-through best practices of the code world (e.g., GitOps).

The thing is, even if we have our policies managed as code, this does not give us the ability to create, manage and enforce them in a way that anyone in your organization can use. If only your developers know how to operate this system (i.e. generate new policies, or modify existing ones by writing policy code), they become bottlenecks in your app’s permission management, leaving other stakeholders locked out of the conversation. Every time a non-technical user, be it from your own organization or your end user, will need to make changes to the policy, they will be fully dependent on your developer team to do so. 

The solution is creating or adopting a solution that provides no-code interfaces which allows creating policy as code. This UI will need to be accessible to every relevant stakeholder, allowing them to take part in the permission management process. 

Is your authorization built to scale and evolve?

Your application and organization are (Hopefully) going to grow. This will require the application to support more users, requests, and data (Not to mention features - more on that in a sec). When building authorization, it is crucial that you plan ahead and structure it in a way that allows for easy modification and expansion. Note that building an authorization system that can handle scalability requires significant expertise and resources. 

As your business requirements change, your security system needs to evolve with them. Building your own authorization system requires constant maintenance and updates to keep up with changing business requirements. This can be a drain on development resources and may result in delays in delivering new features or fixing bugs.

Netflix is a good example of this, and there’s a lot to learn from how they approached building their authorization layer, and the challenges they faced when moving from RBAC to ABAC. 

If you don’t plan for it accordingly, something as simple as adding attributes to an existing RBAC layer (If, say, you now need to monitor access to certain resources based on Time, Geo-Location, or any other type of ABAC rule) could mean completely refactoring your entire authorization system.  

Pros of Building Your Own Security Components

Building your own authorization system gives you complete control over the code and allows you to tailor it perfectly to meet your application’s needs. This can be especially important if your application has unique business requirements or need to integrate with legacy systems that may not be supported by third-party solutions. Additionally, building your own authorization system can be a valuable learning experience, giving you a deeper understanding of security principles and best practices. That being said - it's all a question of what your organization can actually afford in terms of time and workforce allocation.

Conclusion

Building your own security features, specifically authorization, can be a challenging and time-consuming process that most organizations, especially small ones, cannot afford. While there are some benefits to building your own solution, including customization and learning opportunities, the risks and challenges outweigh the benefits for most organizations. Good third-party authorization services can offer a secure solution that can scale, evolve, and, most importantly, save you the time and effort of building, implementing, and maintaining your own authorization layer. Ultimately, the decision between build-or-buy depends on your specific needs and resources, but it's important to carefully consider the trade.

Want to learn more about implementing Authorization? Join our Slack community, where hundreds of devs, including top authorization professionals, are building and implementing authorization.