I coded the security system myself, it is very secure, because it doesn't work.
Security features: We all need them, but should we build them ourselves?
Welcome back! Daniel here again with another weekly digest 💌
This week, we’ll discuss the age-old question of building vs. buying when it comes to application development, especially when it comes to security features. Let’s dive right in -
One of the things we love to do as developers is reinvent the wheel in an infinite array of creative shapes. That and solving problems that don’t exist. It’s true that sometimes, reinventing the wheel yields results that make our bosses very rich. In most cases, though, we end up either building something just to realize it was already built better dozens of times before or realizing that what we spent months building doesn’t really solve the problem.
Sometimes, issues in our application are better resolved if we rely on the work and expertise of our fellow developers. If that sounds like a terrible idea - You can help this list by expanding it.
Take security, for example. Security is not something developers like to think about. Most of the tasks involved in the process don’t include developing new features, and the work tends to be repetitive and tedious. That’s why developers usually tend to like it when they can outsource their security to others.
In some areas, like authentication, a solid consensus has been established in recent years that developers should not roll their own. It’s considered impractical, redundant, and above all - just plain dangerous. You don’t want to play around when it comes to security features - the smallest exploit in your application’s security system can lead to the entire operation collapsing. It's something we’ve seen A LOT of in recent years.
As always, this topic tends to spark some pretty heated debates on Reddit, with replies ranging from this:
To this:
This shift isn’t just limited to the security space - building your own payment infrastructure instead of using solutions like Stripe has been considered absurd for a while now.
To sum these points up, we wrote a piece dedicated to aiding you in the decision of whether to roll your own RBAC, as well as a guide with best practices to help if you decide to go for it.
That being said, and with Auth consistently in the top-3 OWASP vulnerabilities, some security features still require direct developer attention. There are three possible ways to approach this - Standards, Open Source, and Developer Platforms.
Standards have been around since the very beginning of Identity Access Management. Great examples of such standards are OAuth and JWTs. OAuth (the wonderfully confusing authentication standard literally called Open AUTHorization) allows developers to ensure they provide the right access for every federated identity, while the JWT helps with token-based authentication. Still not sure what the difference between the two is? Check out this guide that will help you tell the difference.
Open Source is the next thing to look at if standards aren’t enough for your implementation. While there are endless possibilities for solving Auth problems with open-source tools, we put together a comprehensive list of solutions that will allow you to put some order in the chaos. We highly recommend checking out OPAL, SuperTokens, and Hanko.
Developer Platforms such as Permit.io can help you build authorization without too much hassle. From simple features such as authorization Audit Logs to implementing Relationship Based Access Control (ReBAC) or creating Custom authorization policies, implementing these features yourself can be quite the hassle, so it’s nice to have them ready out of the box. Adopting a tool to help you solve problems doesn’t necessarily mean refactoring your entire system - it’s always better to start simple and adopt the new solution gradually.
By the way, outsourcing security features is not something only relevant for small organizations or independent developers - We’ve just recently covered the Reddit team efforts in solving their authorization challenges with with Open Policy Agent. It is also good to remember that companies as large as Netflix paved the way for many others to create a fine-grained authorization system based on OPA.
Want to support our open-source project? Give OPAL a star on GitHub, and join our Slack Community!
Finally, make sure to subscribe to our Substack for more insightful updates. Share this with your friends and invite them to join our growing community! 🌟