By Emre Baran, CEO & Co-Founder of Cerbos
Authentication and authorization are the two central pillars of the security of any application. Authentication is the identification of valid users and authorization is the process of determining what those users are allowed to do. User authorization plays a crucial role in securing access to your application by handling the privileges assigned to users, groups, or roles. This way, access to individual routes, components, or services can be restricted based on your business needs.
Authorization is one of the hardest parts of security to get right and one of the most expensive to fix when you get it wrong. A single slip might lead to user data being exposed, leading to a loss of trust and public relations nightmare. For example, Microsoft revealed a network security misconfiguration that led to the leak of 250 million customer support records in 2020. “Misconfigurations are unfortunately a common error across the industry. We have solutions to help prevent this kind of mistake, but unfortunately, they were not enabled for this database.” Needless to say, this doesn’t instill trust in the brand.
Authorization logic includes a lot of layers and a lot of places for things to go wrong. From top-level concerns like assigning permissions to the fine-grained aspects of securing access to individual endpoints, each stakeholder involved must get things right for it to work.
When designing an authorization model, it is best to start out with a simple table of user roles and resources and each defines what actions should be allowed. This logic may begin very simply, such as all users with the editor role can edit a resource. But as the logic is refined, requirements that call for contextual decisions to be made, typically come in. The best example of this is when a user is allowed to do certain actions if they are the person that created or owns a particular resource in a system – for example, only the publisher can delete a tweet. Working through these rules and making them explicit, saves a lot of time down the line when defining authorization logic.
Once the business logic is defined, it is easy to consider the work complete. But, in reality, authorization rules have to evolve with the business needs. Some key moments in the growth of a company, which will trigger roles and permissions to evolve, include:
- Users need to have roles beyond the basic ‘user’ or ‘admin’
- Product packaging changes and now users need to be restricted from accessing certain functionality or enforcing quota
- A system has gone international and now data locality and access is
- a hard requirement needing location-aware permissions
- Support enterprise clients that have specific needs around user groups, hierarchies, and access limits to their different departments
- Working in a regulated industry or going after ISO/SOC2 certification with access control audit compliance needs
- Architecturally a system has evolved and is now made up of different services – potentially in different languages or frameworks – but needs to have a consistent authorization strategy.
Typically, at each of these points in the evolution of a business, developers would have to go back into the codebase and replicate the business logic in code, hoping that the translation is correct. At the end of the day, it is the Product or Security teams that hold the requirements for authorization, and yet they must lean on a development team to implement them, rather than focusing on delivering the actual business value.
This is part of the reason many companies are starting to lean on decoupled, self-hosted authorization layers like Cerbos. These solutions extract all that business logic out of the codebase and place it into policy files that are human-readable – even to non-developers – and most importantly, can evolve independently to the codebase without the need for developer resources. This design pattern is key for scaling authorization logic along with the business – as you reach each of the points outlined above, it is a simple logic change in the policy file rather than a wholesale re-write of application code.
The authorization model in an application can mean make or break when it comes to scaling your business. Implementing a solid foundation should allow you to evolve the business logic without lengthy projects, and enable a company to respond quickly to customer or roadmap demands.
