Posted on Aug 2 • Originally published at permit.io on Aug 2 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.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: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.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).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. 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. 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.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.Templates let you quickly answer FAQs or store snippets for re-use.RBAC? I’m lame. I didn’t know what that acronym meant. 😆I DuckDuckGo’d it! Interesting article. Thanks for sharing and getting me to learn what RBAC is.If you have a moment, I would appreciate it if you’d check out my latest article: Software Developer, Are You Just a Hammer?Hey, thanks for the comment!! Happy that you enjoyed it 😊Sure I'll read it, will put a bookmark for my tomorrow's morning reading 🙂Did you built your own authorization? Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse webbureaucrat - Jul 18 Matt Angelosanto - Jul 26 Gopi Gorantala - Jul 26 Jatin Sharma - Jul 21 Once suspended, gemanor will not be able to comment or publish posts until their suspension is removed. Once unsuspended, gemanor will be able to comment and publish posts again. Once unpublished, all posts by gemanor will become hidden and only accessible to themselves. If gemanor is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Gabriel L. Manor. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag gemanor: gemanor consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging gemanor will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.