DEV Community

Cover image for Authorization needs to be dynamic, declarative, and decoupled
Dan for Cerbos

Posted on

Authorization needs to be dynamic, declarative, and decoupled

Guest article written by Fatuma Abdullahi. Thanks! For more great community content and discussions, join our Slack today!

Authorization mechanisms have traditionally been closely tied to the main application logic, and while this works in traditional monolithic systems, maintaining this coupling becomes harder as application complexity grows.

As authorization is a significant aspect of creating and maintaining secure systems, it is better to have it decoupled (or "externalized"); that is, to reduce the dependence between authorization and core application logic. Decoupling simultaneously increases the reliability of the authorization functionality whilst decreasing the complexity of the core system itself.

It is also advantageous to have authorization logic expressed in declarative terms to describe the rules and expected outcomes. This allows the system to make decisions rather than explicitly stating how decisions should be made, making the authorization system accessible to less technical members of an organization. This leads to a dynamic authorization system, or one that makes real-time decisions as requests come in.

A flowchart that shows the process for user access to a resource. It starts with

Decoupled, or externalized, authorization

Using an authorization system that is external to your primary system offers some hard-to-beat advantages, including:

Enhanced Security

External authorization providers are more secure because they are specialized, and are designed from the ground-up with domain-specific experience. They are more aware of the landscape and know what to look out for better than any team whose focus is pulled in many different directions.

Simpler Policy Management

External authorization providers offer a standard way of writing policies and rules, making policy management predictable and allowing the team to move faster.

Straightforward Scaling

External authorization systems have the concept of scale built in. They can be adapted at any size, and when the application grows or its authorization needs change, the external system grows with it seamlessly.

Advantages of externalizing authorization

Decoupling authorization shares advantages with using an external system because both rely on the separation of authorization and business logic as a central pillar. However, additional advantages appear when using an internally-decoupled system. These include:

Increased System Resilience

Separating authorization logic and rules from your main application increases your systems' resilience as the interdependence between them reduces. This allows your system to withstand outages without affecting all your functions.

Simplified Workflows

Keeping authorization external to your primary system simplifies setting up authorization logic and rules. It keeps the teams' focus on how authorization should look independent of any core logic, reducing chances of blind spots and increasing clarity.

Easier Maintenance

Using separate authorization systems makes maintaining the authorization engine more straightforward because of the decoupling that occurs. This makes it simpler to debug and increases the team's developer experience.

RBAC and decoupled authorization

Role-based access Control (RBAC) is an authorization technique that uses a user's role in a system to determine what resources they can access. It is a common way to enforce authorization across systems by assigning permissions to roles rather than to individual users and then assigning roles to users. When enforcing decoupled authorization, RBAC is implemented by centralizing all roles and their related permissions across the system.

There are some trade-offs when using RBAC to manage authorization, including:

Role Explosion

As a system grows, the number of roles and permissions might rapidly multiply leading to too many role definitions overall. This makes it harder to manage and reason about the authorization policies.

Granular Permissions

Sometimes, RBAC is used even in situations better served by more granular access controls. Scenarios requiring dynamic or context-specific permissions might be better served using other techniques like ABAC (Attribute-Based Access Control), which offer more control and flexibility.

Reduced Flexibility

Making changes to RBAC-based policies can be difficult in a growing system, and changes may cause system-wide repercussions. This can lead to a system being slower in adapting to changing authorization needs.

It is important to consider these trade-offs when designing RBAC-based authorization policies and to consider whether other access control techniques might be a better fit.

Authorization and microservices architecture

Microservice architecture refers to organizing application logic into services that typically carry out one thing and can be deployed independently while loosely coupled. For example, edge functions are microservices.

A flowchart diagram showing a client communicating with an API Gateway, which routes requests to four services: Auth Service, User Service, Payment Service, and Notification Service. Each service connects to its respective database: Auth Database, User Database, Payment Database, and Notification Database.

In a system where the backend isn’t distributed in this way (i.e. monolithic architecture), managing authorization queries is reasonably straightforward, as all the data is available in a central location. The challenge with authorization in a microservice architecture is that the services are separated by definition, and often may not talk to each other, making consistent access control and synchronization hard.

There are several ways to handle authorization in a microservices architecture, including implementing a gateway API (Application Programming Interface) service. Cerbos can be integrated into a microservices architecture as a mechanism deployed alongside microservices (e.g. a sidecar in Kubernetes), such that every service has consistent access to the authorization endpoint.

This flexible approach ensures that policies stay consistent across the entire system, regardless of the many services involved. This further simplifies policy management while enhancing security.

Authorization best practices

There are several principles to keep in mind to help make your authorization system robust and to follow best practices, including:

Principle of Least Privilege

This principle emphasizes that users should only ever have the minimum access to perform the required role and no more. This reduces the risk of unauthorized access and the chances of a breach.

Continuous Monitoring and Logging

Logging authorization requests is good practice. This makes it easier to monitor and detect any anti-patterns. Implementing this makes your authorization system more robust and secure, and it also simplifies compliance and audit procedures.

Separation of Concerns

Keeping authorization logic and policies decoupled increases your system's resilience, as any issues in parts of the application will not bring down the entire system. Additionally, decoupling authorization increases flexibility, extensibility, and maintainability at a system level.

Learn more!

You can learn more about decoupled / externalized authorization using the resources below:

Top comments (0)