When building a secure application, there are plenty of factors to be considered. Who is allowed into the application, how users are allowed in, measures in place to avoid bad actors, etc. But one particularly important factor stands out within the walls of any application: authorization.
In this article, we'll see what authorization is all about, and explore several key authorization design patterns, how they work, and possible scenarios where they may be implemented.
By definition, authorization is the control of someone's access to a resource. It's the process of checking and deciding if someone or something is worthy of carrying out a certain task or seeing certain information. It controls what a user can or cannot do within a system.
Think of where you are right now on this website. You can access this particular webpage and read this article. An editor wrote and posted this article due to their access rights but you can only view it, you can't post. You are free to only read because you don't have the rights of an editor, that's authorization at work.
Consider these three components of an authorization mechanism:
Rules: Also known as policies, these effectively specify who can do what under which conditions. For example, a rule that only "editors" can create new articles on this blog.
Contextual details: This encompasses information about the user, the resource they are trying to access, and the specific circumstances of the request. Details might include the user's department, the time of day, the type of device they're using, or the specific resource they want to interact with.
Checker: Properly referred to as a "policy decision point", this is the thing that uses the rules and details to decide if something is allowed.
Authorization is continuously working behind the scenes in every secure system, constantly ensuring you can only do what you have access to do—nothing more, nothing less.
There are a number of authorization paradigms, each with its own strong points and limitations. We'll go over a few of the most common ones below.
In RBAC, permissions are assigned based on a user's role in an organization. Each "role" (e.g. managers, employees, etc.) has specific access rights given to them. The user then inherits the permissions of that role. This is particularly useful in large organizations as it logically models broad business groups.
ABAC is more flexible. It's considered a more fine-grained approach to authorization, which just means it can handle more complexity by considering more factors. Factors could include user attributes (such as department, role, and clearance level), resource attributes (such as document classification, owner, and creation date), and environmental attributes(such as time of day, location, network, device, IP). It can combine all these to decide access privileges.
In this system, the resource owner controls access to their own resources. they get to grant or revoke access to or from whomever they please. This is often used in file systems such as those on your personal computer. DAC allows you to set permissions on your files or folders, ultimately allowing you to decide who can view or edit them.
In MAC access is based on a system of classification and labels governed by a central authority. The system defines access levels (such as top secret, secret, and confidential) that users can only get if they have the right clearance level. It is a very strict system and is mainly used in environments where data security is critical.
This is a more recent approach that's usually used where access decisions are dependent on the interaction between users and resources within the system. It's especially useful for social networks and team projects (think Facebook and Google Docs).
In ReBAC, your permissions might change based on your relationship to other users or to the data itself. For example, on Facebook, you might be able to see posts from your friends, or friends of friends, but not from people you're not connected to.
To better illustrate these concepts, here are some examples of real-world scenarios where these paradigms would be implemented.
Corporate IT systems usually implement a combination of Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Your job title (e.g. manager, staff) determines your level of access within the system—that's RBAC. ABAC then also makes the system more secure by taking into account other factors such as the time, your location, your device, etc to decide whether or not you should be given access to certain things. This dual approach allows organizations to maintain security and flexibility.
Have you ever tried to reply to a social media post on Facebook or Twitter and noticed that the author limited who can comment? That is authorization in the form of ReBAC + DAC. ReBAC works to give access based on connections (if you're friends or not), and determines what you can see on the person's profile. DAC comes into play when the user controls their privacy settings, e.g. setting visibility or comment access to "friends only".
In such high-security environments where classified information is present, Mandatory Access Control (MAC) is often the model of choice. This system provides rigid centralized control where access is granted only when a user's clearance meets or exceeds the classification level of the information.
When it comes to setting up and managing authorization systems, there are some best practices to follow, but also some challenges to watch out for.
Principle of least privilege: This principle proposes the idea that you should give users access to only what they need to carry out their tasks. If their job requires only a certain level of authorization, it should never go past that. In that way, you can limit the level of damage in the case where a bad actor gains access to the system.
Regular audits and reviews: It is important to continually check the access levels of the users within the system as time goes on—especially in a growing organization where roles change—to ensure everyone has the right level of access.
Scalability considerations: You want your authorization system to be able to scale as your application grows, not just to accommodate increasing traffic, but also to manage a growing number of security rules, users, and roles. A scalable authorization solution can handle this complexity without compromising performance.
Managing complex permission structures: As the system grows it can get complex fast, making it hard to keep track of who has access to what.
Maintaining flexibility while ensuring security: It can be difficult to balance security and flexibility. If a system is "too secure" it can become complete unusable. Therefore it's important to balance the strictness of the system with usability to avoid it becoming cumbersome for users.
Performance considerations: In large-scale systems, you usually want to maintain a certain level of performance. This can be somewhat hindered by continuously checking permissions and thus slowing the system down.
Maintenance of custom authorization systems: Homegrown solutions typically require significant maintenance and scaling as the system grows which is a team effort that could be spent on other features or problems.
Authorization is an incredibly important aspect of every secure system. It is used in almost all digital systems you see today, from your personal computer to your social media platform of choice. It works behind the scenes constantly, checking if you have the required access rights to do what you need to do.
In the end, good authorization is all about finding the right balance; between being secure and being easy to use, between giving people the access they need and protecting sensitive information. When it's done right, authorization is a powerful tool that helps keep our digital lives running smoothly and safely. When it's done wrong, it can leave us vulnerable to security breaches or make systems frustrating to use.
If you want to exchange authorization design tips and ideas with other developers, or just learn more about authorization in general, you should join our Community Slack today!
Book a free Policy Workshop to discuss your requirements and get your first policy written by the Cerbos team
Join thousands of developers | Features and updates | 1x per month | No spam, just goodies.