What is authorization (authZ)?

Authorization is the other half of the 'auth' equation. If authentication is the process of identifying who a user or entity is, authorization (often abbreviated as authZ) is the process of determining what that entity can access or do in an application or system. The business logic that governs this access within a system makes up its authorization scheme.

Authorization schemes can vary in complexity from basic boolean logic (has access/doesn't have access) based on basic attributes to more complex schemes based on multiple inputs and data.

Common authorization patterns

Unlike authentication, authorization and access control schemes are less 'plug-and-play' and can vary quite a bit in implementation and usage. Nevertheless, there are a few common authorization patterns found in systems today.

Role Based Access Control (RBAC)

Role based access control (RBAC) is one of the most popular and widely used authorization schemes. Used primarily in B2B software and SaaS, RBAC involves 3 main entities: users (or subjects), roles and permissions. Permissions define specific actions that can be taken within a system while roles serve as 'containers' for multiple permissions within the system. As an example, a system might have an 'admin' role with permissions such as 'create-report' and 'delete-report' assigned to it. Users can then be granted the 'admin' role in order to be subsequently granted the underlying admin permissions.

Attribute Based Access Control (ABAC)

Attribute based access control (ABAC) is an equally popular and widely used authorization scheme. Similar to RBAC, ABAC policies are used to grant or restrict access to functionality or data in an application. Unlike RBAC which is purely based on permission and/or role, ABAC policies can be driven by one or more specific attributes of an entity or user. For example, an ABAC policy might dictate that any user with a "@warrant.dev" email address has the ability to 'create-report' within a system. This permission is granted based on a specific user attribute (in this case email address) instead of the presence of a specific role. ABAC can be used to drive powerful access control policies but is limited to the explicit attributes of a user or entity.

Relationship Based Access Control (ReBAC)

Relationship based access control (ReBAC) is an authorization model that grants or restricts access based on the explicit and implicit relationships between specific entities. An example of ReBAC in use is the Google Drive model of file sharing and ownership. A Google Doc typically has an 'owner', multiple 'editors' and multiple 'viewers'. So users can have an 'owner', 'editor' and/or 'viewer' relationship with a document. These relationships then further define what a user can do with a document. For example, an 'owner' or 'editor' can change a document's contents but a 'viewer' may only view it. ReBAC can enable more powerful and granular authorization but in practice may require a fundamental change in the application's underlying data model.

Fine Grained Authorization (FGA)

Fine-Grained Authorization (FGA) is a comprehensive framework for enforcing access control through multi-dimensional conditions that extend beyond basic user role. It enables organizations to define permissions based on a combination of factors such as user attributes, resource properties, environmental context (e.g., time, location), and relationships between entitie. For example, FGA could grant a marketing team member edit access to a project document only during business hours if they are assigned to Campaign X and accessing the file from a corporate IP addres

FGA encompasses several underlying models, including Role-Based Access Control (RBAC), Relationship-Based Access Control (ReBAC), and Attribute-Based Access Control (ABAC), allowing it to adapt to diverse use case. Its defining characteristic is the ability to evaluate dynamic policies in real time, making access decisions that reflect current contextual data rather than static rules.

Security concerns and best practices

Improper authorization and access control can lead to severe security vulnerabilities in applications. In fact, the latest OWASP Top 10 lists 'Broken Access Control' as its #1 vulnerability based on occurrence and severity. Authorization and access control vulnerabilities can range from users gaining access to behavior/data they shouldn't be able to access to malicious users exploiting an authorization hole to manipulate or corrupt data at large scale.

Given the scope and severity of authorization vulnerabilities, it's especially important to follow best practices when implementing authorization schemes. Here are a few to consider:

Deny by default (enforce least privileges)

A good rule to follow with authorization is to 'deny by default' or 'enforce least privileges'. This simply means that by default, users should have the bare minimum level of access within a system. This at least ensures that users don't accidentally have access to data or parts of a system that they shouldn't be able to access. One simple authorization scheme to enable this is RBAC. Users can be segmented into different 'roles' that grant more elevated levels of access based on need. For example, an application may have every user start within a 'teammate' role that doesn't allow for privileged access. If a user requires privileged access, they may then be assigned an 'admin' role in the future that grants them the additional privileges. This type of RBAC authorization at least guarantees that all users don't have privileged permissions by default.

As granular as possible

Generally, more granular authorization schemes lead to applications with better security and user experience. In this context, 'granularity' refers to the detail with which authorization policies can be defined. As an example, having an authorization policy that can grant 'editor' access to a specific report within a system is more powerful than having a RBAC-type policy which just defines that 'all admins can edit reports'. The main tradeoff with this approach is that authorization systems that support this level of granularity are more complicated to implement and maintain vs. using more traditional RBAC-type systems.

Implement once and reuse

Authorization logic can become quite complex over time and usually lives close to the business logic of an application. As a result, authorization logic often spreads across a codebase and can get increasingly difficult to review or change. As an example, an application without a centralized RBAC service may have role and permissions checks scattered throughout the codebase and worse, these checks may be implemented differently. This introduces further complexity and increases the chance of security holes within an application. That's why, a best practice for authorization logic, whether it's implemented within the application or in an external service, is to centralize it. This makes it easier to review, make changes and even test the impact of changes as an application evolves.

Make it auditable

Even an authorization system that follows all best practices can be compromised, whether through a bad code-change, misconfiguration or even human error. The first step to recover from a breach often involves understanding the scope of the breach and what data was affected. That's why it's important to ensure that your authorization system has an audit log, ideally one which logs each interaction including the requesting user or entity, the data or query being made as well as the overall result of the operation.

Make it scalable

Most companies start with RBAC: it's relatively easy to implement and can get you off the ground fast. However, as your company scales RBAC alone will almost never be enough. The only question is how fast you will outgrow it and how hard it will be to migrate to a proper solution. Things like role explosion, maintenance complexity, lack of flexibility, and impact on user and developer experience, make RBAC a no-go especially when you want to break into the enterprise world. The solution is always found in fine-grained access control. You might as well think ahead and avoid the common pitfalls that many companies hit.