carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby and Python.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Staff Developer Advocate

Carla Urrea Stabile

andres

I’ve been at Auth0 since 2017. I’m currently working as a Director, Product Management for the Auth0 FGA and OpenFGA products. Previously, I worked in the teams that owned the Login and MFA flows. <br>
I spent my entire 20+ year career building tools for developers, wearing different hats. When I'm not doing that, I enjoy spending time with my family, singing in a choir, cooking, or trying new kinds of local cheese.

Director, Product Management

Andrés Aguiar

In this blog post, we’ll explore the differences between ReBAC and ABAC with an in-depth comparison of OpenFGA and Cedar

Understanding ReBAC and ABAC Through OpenFGA and Cedar

Learn about the history of AI agents, the risks they introduce and how to prevent them with a focus on fine-grained access control.


AI Agents are autonomous systems capable of executing complex tasks, making API calls, and maybe even modifying a production database on your behalf. This evolution introduces a new security challenge and attack vector as these AI agents can introduce a level of unpredictability that some access control systems are not ready to handle.

In this blog post, you’ll learn about the history of AI agents, the risks they introduce and how to prevent them with a focus on fine-grained access control. 

## A Brief History of AI Agents

In the last few years, LLMs have evolved to become the mainstream place for questions, and more recently, they have been increasingly used to call APIs on the user’s behalf, delegate work to other models, etc.

We went from simple chatbots to multi-agent collaboration in a matter of a few years, and they all cover different capabilities: 

* **Chatbot**: Can handle written questions and return text and usually operates in a browser communicating through an API endpoint, everything happens within the application.  
* **Assistants**: Can interpret a request and invoke external tools and services to fulfill it.   
* **Agentic** **System**: Chains several tools in a plan it composed on the fly. They operate by communicating the LLM with multiple other services   
* **Multi**\-**Agentic** **System**: Negotiates tasks with other agents, they operate on an agent-to-agent basis. 

## Access-Control Models Under Stress

Security teams usually reach for Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Permission or Policy-Based Access Control (PBAC), or Relationship-Based Access Control (ReBAC). Each shines in well-structured enterprise software; each shows strain when pointed at AI systems.

* **RBAC** is familiar and easy to audit. Unfortunately, an agent’s “role” can change from moment to moment. A request that begins as read-only can evolve into a code-generation exercise that needs write rights. Constant role hopping either floods your logs or drives teams to grant one oversized role that covers every possible combination.

* **ABAC/PBAC** add context: user tier, branch, time of day, tenant ID. They work well when the agent runtime can surface reliable attributes. The catch is that modern LLM stacks often rely on ephemeral containers or serverless functions where ambient context vanishes with each invocation. Persisting trustworthy attributes across the chain demands extra engineering that many proof-of-concept projects skip.

* **ReBAC** models complex resource graphs elegantly, perfect for mapping “Alice may comment on Bob’s ticket if they share a project.”. When the agent makes dozens of micro-tool calls per prompt, those lookups must complete in tens of milliseconds or users will notice a lag so your ReBAC systems must be fast

<include src="SignupCTA" text="Start building now, " linkText="Sign Up to Auth0!" />

## How Authorization Mitigates Top AI Security Risks (OWASP LLM Top 10)

The [OWASP Top 10 for Large Language Model Applications 2025](https://genai.owasp.org/llm-top-10/) explains the most critical risks for AI software and how to mitigate them. Let’s dig into it with a focus on access control. 

**LLM01 Prompt Injection**  
Attackers craft prompts that overwrite system instructions and steer the model toward harmful outcomes. A way to mitigate it is by implementing Input validation, adversarial testing and prompt isolation. In this context, Fine-Grained Access Control could block any tool call that is not explicitly scoped on the agent's permissions, so even a successful injection cannot reach sensitive operations.

**LLM02 Sensitive Information Disclosure**  
Large models sometimes expose secrets from training data or leak confidential context provided at runtime. Some of the ways to mitigate this is by encrypting secrets, removing them from prompts and adding output filtering. Implementing least-privilege scopes is also a good way to mitigate, for example let’s say you want to get data from patient records, your agent would simply lack permission to perform the request, so disclosure stops at the policy level. 

**LLM03 Supply-Chain Compromise**  
It is very common to use third-party models for agent implementations, which could be poisoned or have plugins introducing backdoors and bias. A way to mitigate this is to sign every artifact, verify checksums, and keep a software bill of materials. Assign each external component its own low-privilege identity.

**LLM04 Data and Model Poisoning**  
Attackers could add malicious examples into training or retrieval stores to change the model behaviour. One good way to mitigate this is by running rigorous data provenance checks and trusted-source allow lists help. In the context of access control, attribute-based rules can mark unvetted data as “not-usable,” preventing the agent from loading it until reviewers clear it. 

**LLM05 Improper Output Handling**  
When you give a response, you need to make sure it is validated and sanitized before passing it downstream to the user. It is important to always treat model output as untrusted, apply sanitization, and replay the action through the same access-control filter a human request would face. 

**LLM06 Excessive Agency**  
This risk is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, for example giving an agent broad autonomy could end in unintended deletions, commits and payments. A way to mitigate this is by starting with read-only scopes, requiring user approval and implementing authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not, for example by using fine-grained authorization.

**LLM07 System Prompt Leakage**  
This risk refers to when the system prompts or instructions used to steer the behavior of the model can also contain sensitive information that was not intended to be discovered. Internal instructions may reveal credentials or allowed APIs. Store prompts server-side, rotate them often and scrub sensitive content, you can also make sure that security controls are enforced independently from the LLM and as OWASP says, *“in cases where an agent is performing tasks, if those tasks require different levels of access, then multiple agents should be used, each configured with the least privileges needed to perform the desired tasks.”*

**LLM08 Vector and Embedding Weaknesses**  
Weaknesses in how vectors and embeddings are generated, stored, or retrieved can be exploited by malicious actions to inject harmful content, manipulate model outputs, or access sensitive information. A way to mitigate this is to implement fine-grained access controls and permission-aware vector and embedding stores, as well as data validation and source authentication. 

**LLM09 Misinformation**  
Misinformation occurs when LLMs produce false or misleading information that appears credible. This vulnerability can lead to security breaches, reputational damage, and legal liability. A way to mitigate with retrieval-augmented generation to retrieve verified information from trusted sources, fact-checking APIs, and human review for high-risk tasks. Access control adds a guardrail by, for example, demanding a second verified source before an important write or financial transaction proceeds. 

**LLM10 Unbounded Resource Consumption**  
Unlimited requests drain budgets or become denial-of-service vectors. To mitigate this risk, you can implement strong access controls, including role-based access control (RBAC) and the principle of least privilege, to limit unauthorized access to LLM model repositories and training environments. You could also implement watermarking to detect unauthorized use of the LLM output. 

## How Fine-Grained Authorization Controls AI Agents

1. **Least-Privilege Identities**  
   Give every agent or plugin its own low-privilege credentials and start each session in read-only mode. Grant extra verbs, such as *write invoice* or *delete file*, only after an explicit, audited elevation step.

2. **Policy Checks on Every Call and Result**  
   Route every tool invocation and any generated SQL, code, or HTTP request through an external authorization service. The LLM can propose an action, but the policy, not the model, decides whether it runs.

3. **Label and Quarantine Data Sources**  
   Tag incoming documents, datasets, and embeddings with trust levels like *unknown*, *partner*, or *verified*. Access rules block agents from training on or retrieving content until reviewers promote its label.

4. **Protect System Prompts and Internal Configs**  
    Store prompts on the server side, remove secrets, and rotate them often. Even if a prompt leaks it reveals little, because the agent’s credentials unlock only the narrow slice of resources it truly needs.

5. **Guardrails for Impact and Scale**  
    Require deterministic or human confirmation for payments, refunds, and code deploys, and apply per-identity rate limits and cost budgets. These measures blunt both hallucinated high-risk actions and runaway resource use.

## Conclusion

AI agents amplify productivity, but without the right access control rules, they also amplify risk. It’s important to treat every agent and plugin as its own low-privilege client, check every request with an external policy engine, and enforce strict boundaries around data and costly actions.

Learn more about how [Fine-Grained Authorization](https://fga.dev) works and how you can use it to [secure your AI Agents](https://a0.to/ai-content) for example by [securing a RAG application with Auth0 FGA.](https://auth0.com/ai/docs/intro/authorization-for-rag) 



Access Control in the Era of AI Agents 

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Let's continue to delve into the issues of Identity support in implementing Business-to-Business (B2B) Software-as-a-Service (SaaS) applications by exploring access control.

In our [previous post](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/), we explored the core aspects of establishing a robust identity system for Business-to-Business (B2B) applications, including multi-tenancy, and customer and user onboarding. We discussed how Auth0's Organizations feature provides the necessary structure to isolate customer data and streamline initial setup.

Once you have the foundation of user management in place in your B2B application, the next critical challenge emerges: not all users within an organization should have the same access. A CEO needs different access than a junior analyst, and an admin for one customer’s Organization should certainly not have access to another customer’s Organization.

This article will dive into the critical realm of authorization, examining how to implement granular access control within your B2B Software-as-a-Service (SaaS) application and how Auth0 helps you achieve this with confidence.

## Using Role-Based Access Control (RBAC)

So the new challenges for a B2B SaaS developer now are: **How do I give different users within an organization different permissions and ensure that these permissions are scoped to their specific organization?**

As I recall helping build a B2B SaaS application, we had a raw version of RBAC implemented. In practice, we simply had roles attached to users and our code checked whether a given user had a specific role before granting access to a resource. This worked well enough in simple cases, but it wasn’t particularly flexible. If we added a new role, we had to change the existing code to include it in our authorization evaluations, even if the new role was only slightly different from an existing role — perhaps by one less permission. Raise your hand if you've found yourself in the same situation.

Auth0's RBAC support is out of the box and integrates well with Organizations. Essentially, a role is just a set of permissions identified by a name. These permissions can then be included in the user's access token or ID token, allowing your application's backend or frontend to enforce access policies. Your code doesn’t even need to know about roles, giving the administrator the freedom to aggregate existing permissions into new roles without any changes to your application code.

In addition, Auth0 allows you to assign roles to users **within the context of a specific Organization**. This enables you to deal with scenarios where users are members of multiple Organizations (not common, but possible). In such a scenario, the user "John Doe" can be an *Admin* for the "Acme Corp." organization but only a *Viewer* for the "Widgets Inc." organization, which prevents permission bleeding across your customer base.

> Here are some resources on RBAC:
> 
> * [Role-Based Access Control](https://auth0.com/docs/manage-users/access-control/rbac)  
> * [Add Roles to Organization Members](https://auth0.com/docs/manage-users/organizations/configure-organizations/add-member-roles)  
> * [Implementing Role-Based Access Control in Your Blazor B2B SaaS Application](https://auth0.com/blog/role-management-auth0-organizations-b2b-saas/)

## Beyond Roles: ABAC and ReBAC for Complex Scenarios

While RBAC is pretty good for many scenarios, you might encounter situations where access needs are more dynamic or granular than a simple role can convey. Consider the case where access to a resource is based not only on user permissions but also on user attributes, such as the department they belong to, or time constraints, such as working hours.

In this case, the challenge becomes: **What if I need more dynamic access control based on user attributes or relationships to specific data?**

To correctly manage these scenarios you need to explore advanced authorization models like **Attribute-Based Access Control** (ABAC) and **Relationship-Based Access Control** (ReBAC).

Instead of defining permissions for roles, ABAC defines access rules based on attributes of the user (e.g., the user’s department or location), the resource being accessed (e.g., the type of document), and the environment (e.g., the hour of the day or the IP address). Auth0 can help gather these attributes and include them in tokens, and you can use [Auth0 Actions](https://auth0.com/docs/customize/actions) to dynamically add claims based on external data sources. The enforcement logic then resides in your application or a dedicated authorization service.

ReBAC focuses on the relationships between entities. Think of social networks: "Can user A see user B's post?" Yes, if "user A is a friend of user B". In a SaaS context, this could be: "Can user X access document Y?" Yes, if "user X is the owner of document Y" or "user X is a member of the project that contains document Y".

ReBAC requires a graph database or a specialized authorization service to model and query these relationships effectively. While Auth0 itself isn't a ReBAC enforcement engine, it provides the identity foundation and can integrate with external ReBAC systems like [Auth0 Fine-Grained Authorization](https://a0.to/auth0-fga-content).

For most B2B SaaS applications, a well-designed RBAC system, possibly enhanced with some attribute checks, is sufficient. However, understanding ABAC and ReBAC prepares you for scenarios where your application's authorization needs grow.

> Check out the following documentation to learn more about ABAC, ReBac, and FGA:
> 
> * [An Overview of Commonly Used Access Control Paradigms](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/)  
> * [How to Choose the Right Authorization Model for Your Multi-Tenant SaaS Application](https://auth0.com/blog/how-to-choose-the-right-authorization-model-for-your-multi-tenant-saas-application/)  
> * [Auth0 FGA](https://auth0.com/fine-grained-authorization)

## Conclusion

In this second part of our "B2B SaaS Identity Challenges" series, we’ve tackled the crucial aspect of granular access control. We moved beyond basic user management to explore how Role-Based Access Control (RBAC) helps define and enforce permissions within Organizations, and how Auth0's out-of-the-box RBAC support simplifies this for developers. We also touched upon advanced authorization models like ABAC and ReBAC, preparing you for more complex access scenarios.

While defining who can do what is essential, the real-world demands of enterprise customers extend beyond internal permissions. They require seamless integration with their existing IT infrastructure and a commitment to advanced security measures. In [our next article](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/), we will delve into critical topics like Single Sign-On (SSO), delegated administration, and robust threat protection, addressing the expectations of your largest customers.



B2B SaaS Identity Challenges: Granular Access Control

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Juan Cruz Martinez

Explore how tools like Auth0 Organizations, OPA, and Okta FGA can streamline your authorization strategy for secure, scalable SaaS development.

When building a multi-tenant SaaS application, selecting the right authorization model is critical to ensure the security and scalability of your system. Authorization is not only about managing user access but also about ensuring that tenants remain isolated, protected, and—where necessary—able to collaborate. The right model for your SaaS depends on the complexity of your application, the relationships between users and resources, and how dynamic or flexible your access control needs to be. This guide provides a deeper dive into how **RBAC**, **ABAC**, and **ReBAC** can be implemented for multi-tenancy, focusing on what needs to be handled in code versus what can be centralized in a system. We’ll also touch on popular services like [Auth0 Organizations](https://auth0.com/organizations), [OPA](https://www.openpolicyagent.org/), and [Okta FGA](https://fga.dev/) to streamline your implementation.

## Role-Based Access Control (RBAC)

**Role-Based Access Control (RBAC)** is often the first choice for SaaS applications that have clear roles with distinct access privileges and is often the most familiar option among developers. It’s a straightforward model where users are assigned roles (e.g., admin, editor, viewer), and those roles come with specific permissions. In a multi-tenant environment, RBAC needs some enhancements to ensure roles are properly scoped to each tenant. This way, the users' permissions are restricted to their organization.

In a multi-tenant setup, RBAC handles tenant isolation primarily by scoping roles to individual tenants. This means that roles like “admin” or “viewer” are not globally applicable across the system but are assigned on a per-tenant basis. For instance, a user might be an “admin” in “Tenant A” but only a “viewer” in “Tenant B”.

To enforce this isolation, your application will need to ensure that roles are checked **within the tenant context** before allowing access to resources.

At the **code level**, this means ensuring that the application always verifies which tenant the user is operating under when making role-based decisions. For example, when a user tries to access a resource, the system should confirm whether their “admin” role applies to that specific tenant’s resources, not to another tenant’s resources.

> Notice that when using RBAC for authorization, a user under a certain role will get access to all the resources for that tenant. Other authorization models provide ways to scope the privileges of a user to specific resources within the tenant, and we’ll cover them later in the article.

There are simpler approaches to implementing RBAC into your application; for example, when using Auth0 for authentication, Auth0 offers an **Organizations** feature, which simplifies authentication and role assignments in multi-tenant environments. Auth0 Organizations allows you to easily manage users across multiple tenants (or organizations), where each user can be assigned roles specific to the organization they belong to. By using Auth0’s built-in support for multi-tenancy, you can delegate much of the tenant-specific role management to the identity provider, reducing the amount of tenant-scoped logic that needs to be hardcoded into your app.

### Example use cases for RBAC:

- **HR Management Platform**: In an HR platform used by multiple companies, each company (tenant) has its own set of roles, such as "HR Admin" and "Employee." When an HR Admin from Company A logs in, their permissions are limited to the records of Company A, while an HR Admin from Company B has access only to their company’s records.
- **AI-Powered Customer Support Tool**: A SaaS platform for AI-powered customer support allows companies to manage their support teams. Each team has a role structure, where the "Team Lead" has access to configure the AI responses, and the "Support Agent" can only see suggestions.

## Attribute-Based Access Control (ABAC)

ABAC allows you to define access control policies based on various attributes related to the user, resource, or environment. Unlike RBAC, which assigns static roles, ABAC dynamically evaluates attributes such as the user’s department, resource sensitivity, or even contextual factors like time and location. This makes ABAC more flexible for scenarios where access decisions depend on dynamic conditions.

In multi-tenant SaaS applications, ABAC can handle tenant isolation by including the tenant ID as an attribute in access control decisions. For instance, you can create policies that grant access to users based on their `tenantId`, `role`, and `department`. This allows for more granular control over what users from each tenant can access and when.

At the **code level**, the application needs to collect the relevant attributes (e.g., `tenantId`, `userRole`, `resourceSensitivity`) and pass them to the authorization engine for evaluation. The actual logic for determining whether access is allowed is centralized in the policy engine, reducing the need for complex, tenant-specific logic in your app.

There are some caveats, though; while ABAC allows for dynamic evaluation of the information, the relationships and structure of the information are hardcoded throughout the application, and if your attributes change, it may require code changes throughout the application. This is because the relationships between a user, its role, tenant, etc, are not inferred by the policy engine, but rather specified during authorization checks. For an inferred and more fine-grained approach, there’s a different authorization model which I will cover next.

For **system-level implementation**, ABAC policies can be managed using tools like **Open Policy Agent (OPA)** or a custom policy engine. These tools evaluate attributes dynamically, ensuring that access is granted only if all conditions are met. For multi-tenancy, this would include ensuring that users are only accessing resources within their tenant.
`

### Example use cases for ABAC:

- **AI-Driven Healthcare SaaS**: A hospital management system uses ABAC to grant access to patient records based on a doctor’s role, department, and the patient’s condition. Additionally, access is restricted to working hours.
- **AI-Powered Marketing Platform**: Marketing managers can access reports based on their role, the campaign they are working on, and the region of the campaign. ABAC policies check the region, `campaignType`, and `role` attributes to ensure the user is accessing data for their tenant’s campaigns only.

## **Relationship-Based Access Control (ReBAC)**

**Relationship-Based Access Control (ReBAC)** is ideal for SaaS applications where access control is based on complex relationships between users, resources, and organizations. Instead of simply granting permissions based on roles or attributes, ReBAC models relationships (e.g., "is the owner of," "can edit") and uses these to make access decisions. This is particularly useful for collaborative SaaS platforms where permissions are based on how users interact with resources.

> If your SaaS application handles user-generated content, you’ll likely benefit from a ReBAC model)

In multi-tenant ReBAC implementations, tenant isolation is enforced by defining relationships within and across tenants. For example, a user might "own" a resource within one tenant, and another user might have "edit" permissions for that resource based on their relationship. Unlike RBAC, which assigns roles based on predefined hierarchies, ReBAC focuses on how entities (users, resources, tenants) are related.

At the **code level**, your application doesn’t need to hard-code tenant checks. Instead, all access control decisions are based on querying the relationship graph, which models how users and resources are linked. This reduces complexity, as the app doesn’t need to maintain tenant-specific logic.

For **system-level implementation**, **OktaFGA** (or **OpenFGA**, based on Google Zanzibar’s model) provides a powerful platform for managing ReBAC at scale. OktaFGA stores and manages relationships in a graph database and allows your application to query these relationships in real time. You can model tenant-specific relationships and even handle cross-tenant scenarios, such as allowing external collaborators limited access to certain resources.

### Example use cases for ReBAC:

- **AI-Enhanced Document Collaboration Platform: In this multi-tenant SaaS, users can create, share, and edit documents within their tenant. ReBAC models relationships like "owner," "editor," and "viewer" for each document.**
- **AI-Powered Learning Management System**: A university (tenant) uses the platform to manage courses and student access. Students are "enrolled" in courses, and professors "teach" those courses. ReBAC models these relationships, ensuring that only enrolled students can access course materials. If a student transfers to a new university (tenant), their access is automatically updated based on their new relationships within the system.

## Summary

When it comes to building a multi-tenant SaaS application, your choice of authorization model determines how much of the access control logic is handled by your code versus the authorization system and how wide or fine grained the access control is over the resources of the tenants.

- **RBAC** requires tenant-specific role checks in your code, but tools like **Auth0 Organizations** can offload much of this complexity by managing roles and tenants externally.
- **ABAC** offers fine-grained, context-aware access control, where the system dynamically evaluates policies based on attributes like `tenantId` and `role`. Tools like **Open Policy Agent (OPA)** can centralize these decisions, reducing the need for custom code.
- **ReBAC** excels in scenarios with complex, dynamic relationships. Solutions like **OktaFGA** allow you to manage relationships at scale without embedding tenant-specific logic in your app. Instead, the relationship engine handles access control based on real-time relationships between users and resources.

By leveraging these models and tools, you can build a secure, scalable, and maintainable multi-tenant SaaS platform that fits your unique authorization needs.

Thanks for reading!

How to Choose the Right Authorization Model for Your Multi-Tenant SaaS Application

There are different ways to implement an authorization system and the one you choose depends on your application's needs. Attribute-Based Access Control (ABAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

Previously on your access control series \*read with TV show presenter's voice\*... You learned about [Role-Based Access Control (RBAC) and how to integrate it into your Rails API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/).
In this blog post, you’ll continue learning about different authorization systems, this time about Attribute-Based Access Control and how to migrate the access control of the expense management API from RBAC to ABAC. 

<details>
<summary>Starting from here?</summary>

If you want to start this tutorial from the beginning, [start from this blog post.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/)

Clone the application repo and check out the `add-rbac` branch:

``` bash  
git clone -b add-rbac https://github.com/auth0-blog/rails-api-authorization 
```

Make the project folder your current directory:

``` bash  
cd rails-api-authorization
```

Then, install the project dependencies:

``` bash  
bundle install
```

Then, setup the database

``` bash
  rails db:setup
```

Finally, create a `.env` hidden file:

``` bash  
touch .env
```

Populate `.env` using the `.env.example` file:

``` bash  
cp .env.example .env
```

Add your Auth0 configuration variables to the .env file and run the project by executing the following command:

``` bash  
rails s
```

</details>

## What Are Attributes in the Context of Access Control?

Let's consider the use case of the expense management API you are using in this tutorial. For RBAC, you created an `admin` role and assigned it to users using Auth0 Actions. Users with the `admin` role can approve and review expenses, and so far, that's so good. 

The following requirement you have is that only certain users can do certain things on specific expense reports: 

- Users can only see a report they own (submitted by them)
- Users can only see a report if they are the approver
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

With the current RBAC implementation, a user with the `admin` role can do all of these things, but unfortunately, not all admin users need to approve reports. So, as a solution, you think adding these guards to your code sounds good, so **you are going to check the attributes of the report** (the user is either the approver or submitter of this report), the date the report is being approved, etc. 

This practice has a name, and it's called Attribute-Based Access Control.

## What Is Attribute-Based Access Control (ABAC)?

[According to NIST, Attribute-Based Access Control (ABAC)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf) is an access control method where a subject's requests to perform operations on objects are granted or denied **based on assigned attributes of the subject, assigned attributes of the object**, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.

In other words, any access decision that your application makes based on attributes of an entity can be considered ABAC and it'll be specific to your application and access control needs. 

ABAC also gives you more control and granularity over your access decisions, making it more flexible than RBAC. 

Regarding the expense management API, RBAC and ABAC can coexist; in fact, checking for a role or permission is also checking for attributes, in this case, attributes assigned to the user, so we can say RBAC is an implementation of ABAC with a limited scope of roles and permissions. So now, let's say it is a requirement that the user also needs to be an admin to perform the approver actions. Why not? 😛 

Let's look at what you'll need to change in your Ruby on Rails API to comply with the new access control requirements and implement ABAC. 

## ABAC Implementation in a Ruby on Rails API

Let's take a look at the requirements you need to implement: 

- Users can only see a report they own (submitted by them)
- Only approvers can see reports submitted by other users
- Only admin users can approve reports
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

Based on this, there are a few changes you could make to the application; most of them are related to the `report` entity. 

Let's think of the scenario where a **user can only see a report they have submitted, or they are the approver**; you could think of this as multiple things like the user needs to have some relationship with the expense report, meaning they are either the submitter or the approver.

There's little we can do with the relationship example now. Still, you can define that if a user is the submitter or approver of a report, they have some **ownership** over it and are allowed to see that report, so let's start there. 

In the API context, you can define this ownership such that **the user making the request is the same user for which we want to see reports.** At the moment, your API doesn't have the context of the user other than an access token, which tells you only that they are authorized to access your API and that they are `admin` because [you added this role as a custom claim in the access token.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Creating-and-Assigning-Roles-with-Auth0)

So, that's great 🫠 how can you get information from the user in your API using Auth0? The answer is by connecting your Auth0 API and your Auth0 Application!

### Connect Your Auth0 API with your Auth0 Application 

If you have a REST API as your backend, chances are you have a frontend application where your users authenticate and manage their data, etc. 

When you use Auth0, your users can authenticate using [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login). So, you need to create an Auth0 Application for either a SPA or a Regular Web Application and [integrate it with your code using one of the SDKs](https://auth0.com/docs/libraries). For this blog post, let's focus on the example of the regular web application. 

[When you created the expense management API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Building-the-Starter-Application), you created an [Auth0 API](https://auth0.com/docs/get-started/apis) and an Auth0 Regular Web Application for testing purposes, well now you are going to use this Regular Web Application because in a real-life scenario, your users will probably authenticate themselves *somewhere* and once they're authenticated you proceed to do X or Y in your REST API. 

In the Regular Web Application you created in Auth0 for your users to authenticate, you need to implement login, logout, etc., and you can learn how to do so by following [any of the Developer Center Guides on Authentication](https://developer.auth0.com/resources/guides?type=web-app). Still, the general process is almost identical in all of them, and the outcome is that **you will get an access token from Auth0 issued for the authenticated user.** 
 
Then, you need to tell your Regular Web Application that your users will be interacting with your REST API and, therefore, its counterpart in Auth0, so when you request the access token, you need to provide the `audience` as well. An example of how to do this in a [Ruby on Rails Web application](https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication) would be: 

```ruby
Rails.application.config.middleware.use OmniAuth::Builder do
 provider(
 :auth0,
    AUTH0_CONFIG['auth0_client_id'],
    AUTH0_CONFIG['auth0_client_secret'],
    AUTH0_CONFIG['auth0_domain'],
 callback_path: AUTH0_CONFIG['auth0_callback_path'],
 authorize_params: {
 scope: 'openid profile email',
 audience: 'https://rails-api-authorization', # pass the audience ✨
 }
 )
end
```

Once you pass the `audience`, you'll get a JWT token containing the information about the user, as well as any scopes and claims you've added. To learn more about the audience parameter [you can check out this post.](https://community.auth0.com/t/what-is-the-audience)

That's all you need to do for now in Auth0 to make this work, so let's get back to the code!

### Validate Ownership of the User Making the Request

You already added a method to check for the user's role, so similarly, you could do the same to check for the user's *ownership*. In the context of the expense management app, we'll say: 

> A user is allowed to see an expense report of another user if they are the subject of the access token 

At the moment, you do not store any information about the user's data in your database, but you will need the Auth0 user's ID to compare it. 

#### Add the Auth0 ID to the User Model

Let's create a migration to add a new field to the User model using the following command on your terminal: 

```bash
rails g migration AddAuth0IDToUsers auth0_id:string 
```

The command above will generate a new migration file under `db/migrate/YYYYMMDDHHMM_add_auth0_id_to_users.rb` that looks like this:

```ruby
class AddAuth0IdToUsers < ActiveRecord::Migration[7.0]
  def change
 add_column :users, :auth0_id, :string
  end
end
```

Then, execute the migration by running `rails db:migrate` on your terminal. 

Now, let's add a validation to the User model to make sure the `auth0_id` field is always present and unique. Go to `app/models/user.rb` and add the following code: 

```ruby
class User < ApplicationRecord
 has_many :expenses, foreign_key: :submitter_id
 has_many :submitted_reports, class_name: 'Report', foreign_key: 'submitter_id'
 has_many :reports_to_review, class_name: 'Report', foreign_key: 'approver_id'

 validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }, presence: true, uniqueness: true
  # 👇 new code 
 validates :auth0_id, presence: true, uniqueness: true
end
```

You're all set from the model level. Let's move to the controller level. 

#### Add the Ownership Validation to the Controller

Go to the `Secured` concern in `app/controllers/concerns/secured.rb` and add the following code: 

```ruby
# frozen_string_literal: true

module Secured
  extend ActiveSupport::Concern

  REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze
  BAD_CREDENTIALS = {
 message: 'Bad credentials'
 }.freeze
  MALFORMED_AUTHORIZATION_HEADER = {
 error: 'invalid_request',
 error_description: 'Authorization header value must follow this format: Bearer access-token',
 message: 'Bad credentials'
 }.freeze
  INSUFFICIENT_ROLES = {
 error: 'insufficient_roles',
 error_description: 'The access token does not contain the required roles',
 message: 'Permission denied'
 }.freeze
  # 👇 new code 
  NOT_OWNER = {
 error: 'not_owner',
 error_description: 'The access token does not belong to the current user',
 message: 'Permission denied'
 }.freeze
  # 👆 new code 

  def authorize
 token = token_from_request

 validation_response = Auth0Client.validate_token(token)

    @decoded_token = validation_response.decoded_token

    return unless (error = validation_response.error)

 render json: { message: error.message }, status: error.status
  end

  def validate_roles(roles)
    raise 'validate_roles needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_roles(roles)

 render json: INSUFFICIENT_ROLES, status: :forbidden
  end

  # 👇 new code 
  def validate_ownership(current_user)
    raise 'validate_ownership needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_user(current_user)

 render json: NOT_OWNER, status: :forbidden
  end
  # 👆 new code 

  private
  # ... 
end
```

You are adding a new hash called `NOT_OWNER` to specify the error message in case the user is not the owner of the access token being passed. Then, in the `validate_ownership` method, you're checking the access token and returning an error if the user is not the owner. Since you haven't implemented the `validate_user` method yet, let's add it to the token structure. 

Go to your `Auth0Client` class in `app/lib/auth0_client.rb` and add the following code: 

```ruby
# frozen_string_literal: true

require 'jwt'
require 'net/http'

class Auth0Client

  # Class members
  Response = Struct.new(:decoded_token, :error)
  Error = Struct.new(:message, :status)
  Token = Struct.new(:token) do
    def validate_roles(roles)
 required_roles = Set.new roles
 token_roles = Set.new token[0][Rails.configuration.auth0.roles]
 required_roles <= token_roles
    end
    # 👇 new code
    def validate_user(current_user)
 current_user.auth0_id == token[0]["sub"]
    end
    # 👆 new code
  end

  # Helper Functions
  # ...
end
```

The `validate_user` method checks the `current_user` variable (the user from whom you want to check the reports) against the owner of the access token. In the access token, you have information about the user's ID in Auth0 under the `sub` field, so you are comparing that against the `auth0_id` from the local database. 

Next, call the `validate_ownership` method in the `ReportsController`. You want to validate the user's ownership when they request to review or submit a report, so let's add the validation to the corresponding actions. 

Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  def submitted
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(submitter_id: @user.id) # list only reports where user is submitter

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/review
  def review
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(approver_id: @user.id) # list only reports where user is approver

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/1/approve
  # ...
end
```

By adding the `validate_ownership` block in the controller together with the condition inside the query, you are implementing a form of ABAC because you're allowing or denying access based on certain attributes of the user or the report. 

### Validate that Only Approver Users can Approve Reports 

Even though this might be a new requirement, you already took care of this scenario when you first added RBAC. If you look at the `approve` action in the `ReportsController`:

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  # ...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        @report.status = "approved"
        @report.save
 render json: @report
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

The check for `@report.is_approver?(@user)` already confirms that 
 `@user` is the approver of `@report`. This is interesting because sometimes we mix up different authorization models without even realizing it, and that's okay as long as it fits your business model. s

### Validate that Approvals Only on Weekdays

You only have to add another validation to allow users to approve expense reports on weekdays, and this is possible by adding a new check to the `approve` action in the `ReportsController`. Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  #...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        # 👇 new code 
        if Date.current.on_weekday? # can only approve on weekdays
          @report.status = "approved"
          @report.save
 render json: @report
        else
 render json: {message: "Can only approve on weekdays"}, status: 401
        end
        # 👆 new code 
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

[The function `Date.current.on_weekday?`](https://api.rubyonrails.org/classes/DateAndTime/Calculations.html#method-i-on_weekday-3F) returns true if it's a weekday (Mon-Fri) and false otherwise. Users who try to approve during the week will get an error.

At this point, you've fulfilled all the requirements you've received so far! 🚀 It's time to go back to the client and discuss the progress you've made. 

> Up until here, all the changes in the code are available in the [`add-abac` branch of the repository.](https://github.com/auth0-blog/rails-api-authorization/tree/add-abac)

## What About Policies?

You're introducing a lot of extra complexity in the application code that needs to be recreated by each environment, such as web, mobile, CLI, etc. Using a policy engine can streamline application decision-making. 

[A policy](https://csrc.nist.gov/glossary/term/access_control_policy) is a set of rules defining a software service's behavior. There are access control systems like [Open Policy Agent (OPA)](https://www.openpolicyagent.org/), a full-featured policy engine that offloads policy decisions from your software so you don't have to implement it from scratch, or [Policy-Based Access Control (PBAC)](https://csrc.nist.gov/glossary/term/policy_based_access_control), where access control decisions are made based on the business roles of users and is combined with policies.

You won't implement PBAC for the sake of this tutorial, but I thought it was interesting for you to know that decision-making engines like these exist.

## Oh, No. What's Next?

You are showing your implementation to the client, and they're satisfied, but as usual, they came back with more requirements 🥲 

- Users who are managers can see the reports of their directs, plus the reports of their directs' directs, and so on 😵‍💫

You think of a way to implement this with your current solution and... recursiveness 🥲 you know this is possible, but you also start exploring what options are out there for these scenarios. You bump into Relationship-Based Access Control, which seems interesting 🤔 because you feel like basing your implementation on the relationships of your users could work, but you need to do more research. 

## Conclusion 

When we talk about attributes, we refer to properties of the entities of your application; in the expense management application example, we are talking about attributes of a user or an expense report. Attribute-Based Access Control is an authorization model that allows you to make decisions based on these attributes. ABAC gives you more granularity than RBAC because you can specify access control on specific resources other than a role that usually includes more than one resource. 

In the next blog post, you'll learn about ReBAC and its implementations. 

How to Implement Attribute-Based Access Control (ABAC) in a Ruby On Rails API?

Sam4-square

I'm an Identity nerd with many years of experience as a developer and advocate. I love explaining complex topics clearly and understandably. You can find me on stage at developer events worldwide or simply having great conversations in the hallway. Google has recognized me as a Google Developer Expert (GDE) in the domains of Web Technologies, Security, Privacy, Payments, and Identity.

Sam Bellen

When you are working on a complex web application, at some point, you’ll want to restrict or grant access. In this post we'll explore some of the most commonly used access control paradigms.

Whether you are working on a complex web application, managing a hosting infrastructure, or configuring your company's applications, at some point, you’ll want to restrict or grant access to specific people, groups, or applications, depending on some properties. These can be a role or permission, the time of day or location, or the relationship between two entities. Based on your scenario and the level of complexity, one or more access control approaches might work for you.

## Coarse-Grained (CGA) Versus Fine-Grained Access Control (FGA)

We can distinguish two general strategies based on how granular you want to be when making access control decisions. You either choose a coarse or fine-grained approach.
A coarse-grained approach assigns permissions to a large group of users and resources.
A fine-grained approach looks at the bigger picture, taking into account a lot of different data points and scenarios or assigning permissions to a more limited group of users and resources, or even unique permission per user and resource.

Both strategies have their place, and choosing the level of detail you want to include in your access control decisions might influence the paradigms you can use. For example, a role-based access control usually implements coarse-grained access control, while the relationship-based access control approach is ready to make very fine-grained decisions.

## Role-Based Access Control (RBAC)

The first access control paradigm we’ll discuss in this article is **role-based access control**. It is the most commonly used approach and the simplest to start with. Role-based access control, as the name implies, uses a system of roles and permissions to make a decision.

A role is a collection of permissions that can be assigned to a user, and a permission indicates a certain allowed action that can be performed by any user assigned a role containing this permission. For example, a `guest` role might have permission to view all posts on a website, while an `admin` role could have both a view and delete permission attached to it.

```shell
guest: [
  view:post
]

admin: [
  view:post,
  delete:post
]
```

Your application can either check if the current user has `delete` permissions or has been assigned the admin role. Either scenario will let your app know the user should be able to delete posts. Checking for permissions over roles offers the benefit that your application doesn’t need changes when roles and their permissions change over time.

To get the roles or permissions, your application typically requests them from a user-info endpoint, or your authorization server adds them to the access and/or ID tokens issued when the user is authenticated.

Because we check for permission based on a resource type rather than a specific resource like `post x` or `post y`, RBAC is an example of a coarse-grained access control approach.

## Attribute-Based Access Control (ABAC) or Policy-Based Access Control (PBAC)

**ABAC** or **PBAC** is an access control strategy in which a decision is made based on assessing attributes related to a request or situation. Policies define how these attributes are evaluated. The most common types of attributes are **user** (role, job title, security level), **environment** (time of day, location), **resource** (resource type, data sensitivity), and **action** (read, write, delete). Combining multiple attributes into one or more policies offers a highly customizable and fine-grained solution to grant or limit actions within your applications or systems. The more policies you create, the more control you have over your access decisions, but the harder it becomes to maintain these policies.

An attribute-based access control system often consists of at least a decision engine and a policy language you can use to describe scenarios and their outcome. The same is true for ReBAC, but more on that later.

The decision or policy engine will evaluate data presented in a request against one or more policies written in the policy language. The downside is that you first need to gather the relevant data before passing it to the decision engine for evaluation. This often requires some extra database lookups.

If, for example, you’d like to check if a user can view a document in a parent folder owned by the same user, you’d first need to read the document database table. You'd then search the parent folder for that document and check if a user has access to that folder. Once you’ve done the lookup, you can pass this information to the policy engine to make an informed decision. 

### Open Policy Agent (OPA)

[Open Policy Agent (OPA)](https://www.openpolicyagent.org) is a declarative policy engine that strongly focuses on access control for infrastructure like Docker or Kubernetes containers. Their homepage describes OPA as “Policy-based control for cloud-native environments, flexible, fine-grained control for administrators across the stack.”. This doesn’t mean you can’t use it for other use cases, but it is best suited for managing infrastructure access.

Open policy agents are usually deployed as a “sidecar” beside your applications or infrastructure. This sidecar contains all policies and some relevant data in JSON files. If you run multiple applications, containers, or clusters, it can become a difficult chore to keep all policies and data up-to-date across all OPA sidecars.

Let’s look at an example. If a request comes from an origin we have on a disallow list, the policy engine will return a negative decision. For this to work, we would have written a policy that specifies that the engine looks through a list of blocked origins and checks if the origin, which is part of the request to the decision engine, is part of that list.

OPA policies are written in REGO, a generic programming language that allows you to write detailed policies. Because it is a generic language, it has a steep learning curve and usually takes some time to get used to.

Some [pseudocode](https://play.openpolicyagent.org/p/THKqtQ3QME) for the example above written in [the REGO language](https://www.openpolicyagent.org/docs/latest/policy-language/) would look like the following. 

```shell
deny[reason] {
    disallowedOrigins := ["blocked.com","malicious.com"]

    some input.request.origin in disallowedOrigins
    reason := sprintf("origin %s has been blocked", [input.request.origin])
}
```

Because Policy engines are usually built to make split-second decisions by evaluating a limited dataset against a mostly static set of policies, they are perfect for infrastructure scenarios without constant changes to the data or the policies. Therefore, there’s no need for a scalable, consistent way to add or remove decision data within these engines. 

This might become an issue when dealing with application access control, especially if your application deals with many users who create or manage content. Each time a user performs an action, your application needs to gather all relevant data points before passing them on to the policy engine. Because of this, the latency of your request depends more on how much time it takes to gather this information than on how fast your decision engine can evaluate its policies. As your application scales, so does your data. These lookups can become a bottleneck for fast and reliable access control decisions.

Luckily, the next access control strategy I want to discuss, relationship-based access control, is built just for these use cases.

## Relationship-Based Access Control (ReBAC)

**Relationship-based access control** is a strategy that offers a fine-grained control based on looking at relationships between users and resources, or between multiple (different) resources.

Most ReBAC implementations today are based on Google's Zanzibar paper. In this paper, they describe the system they’ve built internally to handle a variety of access control scenarios across the whole Google ecosystem. This system needs to be flexible enough to handle authorization scenarios for their varied range of products and fast enough not to impact the user’s experience with them. 

To learn more about the Zanzibar paper, visit our informational website [zanzibar.academy](https://zanzibar.academy).

Just like attribute-based access control, ReBAC usually has a decision engine and a modeling language that lets you define relationships the engine will evaluate. New to this paradigm is a database that stores a large and ever-changing set of data related to all users and resources and their relationships. Whenever a user performs an action, this dataset can be impacted.

### OpenFGA 

[OpenFGA](https://openfga.dev) is an open-source solution for Zanzibar-style ReBAC access control. It’s been adopted by the Cloud Native Computing Foundation (CNCF) and actively worked on by members of Okta and the open-source community. OpenFGA uses an easy-to-read domain-specific language (DSL) to model the authorization model and exposes an API to add tuples to a database or query for access control decisions.

<include 
    src="LinkCard" 
    title="Do you prefer a managed ReBAC solution?" 
    link="https://fga.dev" 
    description="Okta FGA is built on top of OpenFGA and takes away the headaches of hosting, scaling, securing, and backing up your data. 
Find out more at fga.dev."
/>

### Direct versus indirect relationships

The relationships defined in the authorization model can be either direct or indirect. Simply put, direct relationships are directly assigned between a consumer and a resource (we call them user and object) and stored in the database. Indirect relationships are the relationships we can infer based on the data and the authorization model. 

We can write our first simple authorization model using OpenFGA DSL to define a `user` and a `repository` type. A repository can have a user or multiple users as a relation. Knowing this, we can assign a user as the owner of a GitHub repository by saving the following tuple in the database:

```yaml
type user
type repository
  relations
    define owner: [user]
```

```json
{
  user: "user:sam",
  relation: "owner",
  object: "repository:fga-demo"
}
```

When we ask the decision engine whether user `Sam` is the owner of the `fga-demo` repository, the engine looks in the database, finds the tuple, and gives us a positive response.

The true power of ReBAC lies in its ability to calculate indirect relationships—relationships that are not explicitly defined but can nonetheless be found between a user and an object. If we expand the GitHub example and add an organization, we can check whether members of that organization can commit to a repository owned by that organization, even if they are not directly assigned as a `repo_writer`.

```yaml
type user
type organization
  relations
    define member: [user]
    define repo_writer: [user] or member
type repository
  relations
    define owner: [organization]
    define can_commit: repo_writer from owner
```

```json
{
  user: "user:sam",
  relation: "member",
  object: "organization:okta"
},{
  user: "organization:okta",
  relation: "owner",
  object: "repository:fga-demo"
}
```

Given this new model and these two tuples, we can query for some direct and indirect relationships.
- Direct: `Sam` is a `member` of the `Okta` organization 
- Direct: The organization `Okta` is the `owner` of the `fga-demo` repository
- Indirect: `Sam` is a `repo writer` for the `fga-demo` repository
- Indirect: `Sam` can commit to the `fga-demo` repository

By examining the relationships between users (consumers) and objects (resources) instead of a static list of roles and permissions, Rebac offers a highly flexible and powerful way to deal with fine-grained authorization decisions within applications.

## Hybrid Access Control Solutions

While most access control products, services, or libraries started out with a specific approach in mind, many of them added (partial) support for other paradigms to be flexible, all-in-one solutions.

Using **OpenFGA**, [Contextual Tuples](https://openfga.dev/docs/modeling/token-claims-contextual-tuples) allow authorization checks that depend on dynamic or contextual relationships not written to the OpenFGA store, enabling some attribute-based access control (ABAC) use cases. For example, allow or disallow an action based on the time of day. You can also use [conditions](https://docs.fga.dev/modeling/basics/conditions) to make your authorization models more flexible.

**OPA** was originally created to deal with ABAC for infrastructure. There are some initiatives, like [TOPAZ](https://www.topaz.sh), that are adding a database to the system, allowing it to make decisions on a larger, more dynamic dataset, just like ReBAC does, avoiding the need to gather all relevant data before asking your policy engine for a decision.

[OPAL](https://www.openpolicyagent.org/integrations/opal/) is another initiative that adds an administration layer to OPA. This layer helps you sync the policies and data in your OPA sidecars across your agents.

## Conclusion

There is **no magic bullet for dealing with authorization in all scenarios** we, as application builders, have to face. 

Considering which approach works well for your situation will help you scale your authorization decisions as your application or infrastructure grows more complex. So, ask yourself whether you’re looking for a simple role-based or finer-grained solution. An attribute or policy-based approach might work great if you're dealing with infrastructure. Still, a relationship-based approach might be the best solution for complex applications, saving you from doing some extra database lookups before making each access control decision.

An Overview of Commonly Used  Access Control Paradigms

Learn which is the right authorization model for your application based on your use case.

Authorization is the process of verifying access to specific resources. In modern systems, using modern security workflows, an application can control what a user is authorized to do; this process is known as access control. 

In this post, you'll learn about access control and why you'll probably want to use an access control model to provide the structure and rules for deciding who can access what.  

Let's think of an example application like an *expense report management system* to walk you through the different access control models. In these types of systems, you want some users to be able to approve the expense reports submitted by other users. 

You start working on an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) for this project and want to iterate as the product evolves and grows. You decide to build it in Ruby On Rails because you are proficient in it. You have built your brand new expense app and are proud of it. It has all the features anyone needs: the ability to create a new expense report, update and delete reports, list and approve, and so on. **Now it's time to restrict who can do what, i.e., to build your authorization system.**

## First Step: Authentication 

You don't want just anyone to access your app and create expense reports or see the existing reports. You need to restrict access to your app to users who are authorized. Who are those users? Well, these are the users that your app recognizes as being authenticated.

If a user provides valid credentials (i.e., is authenticated), then they are authorized to access your app.

Often people [confuse the terms authentication and authorization](https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization), and the main reason is that **authentication is usually the first step in the authorization.** 

> Authentication is the process of verifying someone is who they say they are, and authorization is the process of verifying what they can and cannot access.

Only in very simple use cases is authentication enough to authorize users to use an application. For example, in your expense report app, using just authentication as the criteria for authorizing users leads to potential problems: any authenticated user can create, list, and approve reports. Presumably, this is different from what you want.

So how can you make sure only *some* users can perform operations on your reports? 🤔

## Using Roles

Your users can submit reports, but at this point, you might need a group of users in charge of approving them. It might be a case of defining an "expense approver" role. 

When you are defining your authorization model, and you realize you can **group your users based on their shared responsibilities, you are referring to [Role-Based Access Control (RBAC)](https://auth0.com/docs/manage-users/access-control/rbac).** This model offers a simple, manageable approach to access management that allows your app to determine what a user can or cannot do based on their specific responsibility, i.e., their role.

In Auth0, a [role](https://auth0.com/docs/manage-users/access-control/rbac#roles) is defined as a collection of operations that can be executed on a resource. In this case, you want to create an "expense approver" role to perform the *approve* operation on *expense reports*, which fulfills your current use case. Great! 🙌

At this point, your users can submit reports, and expense approvers can approve them. Although you haven't defined which users can see which reports, meaning **any user could see the report of another user.** 😩 

## Using Permissions

Roles have limitations in access control implementation; the more your application grows, the more complex it is to maintain the list of possible roles. Using RBAC alone can lead to role explosion, meaning you can end up having hundreds of roles to manage. So you decide to also implement permissions. 

> [A permission is a declaration of an action that can be executed on a resource](https://auth0.com/blog/permissions-privileges-and-scopes/#What-Are-Permissions). Permissions defined for an API in Auth0 can be used as part of the access control mechanism used by your application.  

Using permissions allows your application logic to no longer rely solely on roles for access control. Permissions allow you to define more granular access control, and Auth0 also allows you to add permissions to a role as a handy way to assign them to users en masse. 

In this case, you want permission that allows users to read expense reports only if they are expense approvers or the creators of such reports. To implement permissions, you need to add some logic in your application to define which reports a user can see. Let's break this down into two groups: the expense approvers and the rest of the users.  

What you want to achieve is that expense approvers can see all expense reports while the rest of the users can only see their own reports. For the expense approver use case, you can add the permission *read expense report*, say, to their role and define in your application logic that this implies all expense approvers can see all expense reports. So far, so good. The expense approver role still suffices for the use case 🙌.

For the rest of the users to see only their reports, they require the *read expense report* permission. Because they do not have the "expense approver" role, then your application logic can prevent them from reading any expense report except their own. The use of roles in conjunction with permissions allows your application to tell which report(s) the user can read and which they can't.

You could have a method that verifies if the user has the role of expense approver; otherwise, check against your relational database if the user is the submitter of the expense report. In ruby-like syntax, it would translate to something along the lines of: 

```ruby
def can_read_expense_report(user)

  return true if user.expense_approver?

  expenses = db.fetch(
    "SELECT expenses.id, users.user_id
     FROM expenses WHERE id = %
     JOIN users WHERE users.user_id = expenses.submitter_id")

  authorize!(user, :read, :expenses)
end
```

Another option is for you to use an external gem, like [CanCanCan](https://github.com/CanCanCommunity/cancancan) or [pundit](https://github.com/varvet/pundit). Implementation details are completely up to you and your application.    

At this point, each user can see the reports they have submitted, and there is an expense approver role that can see all reports and approve them. You show your application to your stakeholders, and they decide that now **expense approvers can only approve expenses of their direct reports** 😧

You take a deep breath 🧘 and start thinking this through...

## Using Attributes for Access Control

Let's assume that in your system, you know the direct reports of your users because your user entity has a `manager_id` attribute. 

**When you define an authorization system that evaluates attributes (or characteristics), you are using [Attribute-Based Access Control (ABAC)](https://www.okta.com/blog/2020/09/attribute-based-access-control-abac/).** The purpose of ABAC is to protect objects from unauthorized users and actions — those that don't have "approved" characteristics as defined by an organization's security policies.  

In your case, your security policy will be as follows: 

> If user A is the manager of user B, then user A can approve an expense report from user B

Then, in your application code, you have to define the method that executes this policy. Let's say you have this information available in your relational database, and you can run a query to get the expenses of a user and, if they are the manager of the submitter user, approve the expense. A way to do this in *ruby-like (more like pseudo-code)* syntax, similar to what you did with your implementation of permissions, would be:

```ruby
def approve_expense(user)
  expense = db.fetch(
    "SELECT expenses.*, users.manager_id as submitter_manager_id
     FROM expenses WHERE id = %
     JOIN users WHERE users.user_id = expenses.submitter_id")

  authorize!(user, :approve, :expense)
end
```

The code above is similar to the one you wrote when implementing permissions. The key difference is that you are basing your `approve_expense` method and policy on the attributes of an object, in this case, the user. As you see, ABAC, RBAC, and permissions can all be used together. 💡

The `approve_expense` method works pretty great with your application 🥳 so you think of ways to optimize it and make it scalable. In a small organization with only one level of management, your authorization system works well, but when you take it to a bigger organization with multiple levels of management, you realize your solution can cause performance and maintenance issues. 🤔

The above code is **embedding authorization logic in your application code**, making it difficult to understand how authorization is implemented in the system without looking at the source code.

Also, if there are any **changes in your authorization policy, it will require you to change your application code.**

Lastly, every time you need to approve or verify if a user can read an expense report, you are hitting your operational databases, adding more load to those databases and therefore **adding latency to your requests.** 

You see, there is a clear relationship between the expense approver, the submitter, and the expense report; the attribute of being a manager works but adds complexity you don't need, so you decide to take a step back and re-think your implementation.

## I Need to Grant Access Based on Relationships

You were on the right track when you modeled your authorization system based on the user's attributes and the object you're trying to access. But that solution didn't work so well when management changed their mind and the application needed to grow 🙄 So now you decide that instead of using attributes, **it makes more sense to work based on the user's relationships with each other and the expense report too**. And the good news is that there is an authorization model out there that can help you do just that!

**[Relationship-Based Access Control (ReBAC)](https://docs.fga.dev/intro/authorization-and-auth0-fga#what-is-relationship-based-access-control-rebac) allows you to express rules based on relations that users have with objects and that objects have with other objects, providing a more expressive authorization model that can describe very complex contexts.** An example of where you find this authorization model is a social media app, where users can control who has access to their profile or information based on their relationship with other users. 

ReBAC is an example of a model that will typically offer you the most flexibility; models with a high degree of flexibility are often referred to using the term [Fine-Graned Authorization (FGA)](https://docs.fga.dev/intro/authorization-and-auth0-fga#what-is-fine-grained-authorization-fga). At scale, a system could have millions of objects, users, and relations with a high change rate, meaning that objects are regularly added, and access permissions are constantly being updated. An example is Google Drive, where you can grant access to documents or folders and where access can be granted to users individually or as a group. Access regularly changes as new documents are created and shared with specific users, whether inside the same company or without.

A Fine-Grained Authorization model sounds exactly like what you need for your use case 🤩. But wait. Surely something like this will be complex to build, right? Well, yes, it is. However, the good news is that we've already done it for you! [Auth0 FGA](https://auth0.com/developers/lab/fine-grained-authorization) provides an easy solution and offers a way to define your authorization model and relationships between a user and a report using something like the following:

```python
type report
  relations
    define approver: can_manage from submitter
    define submitter: [user]
type user
  relations
    define can_manage: manager or can_manage from manager
    define manager: [user]
```

With this model, you are stating the `manager` relationship between users and that the manager of the submitter is the only one who can approve a report by using the `can_manage` relation.

If you want to check if a user is a manager of another user in the management hierarchy, you could use the [Auth0 FGA Check API](https://docs.fga.dev/api/service#/Relationship%20Queries/Check). In Ruby, it'd look as follows: 


```ruby
require "uri"
require "json"
require "net/http"

FGA_API_URL="YOUR_FGA_API_URL"
FGA_BEARER_TOKEN="YOUR_BEARER_TOKEN"
FGA_STORE_ID="YOUR_STORE_ID"

url = URI("#{FGA_API_URL}/stores/#{FGA_STORE_ID}/check")

http = Net::HTTP.new(url.host, url.port);
http.use_ssl = true

request = Net::HTTP::Post.new(url)
request["Authorization"] = "Bearer #{FGA_BEARER_TOKEN}"
request["content-type"] = "application/json"
request.body = JSON.dump({
  "tuple_key": {
    "user": "user:alex",
    "relation": "can_manage",
    "object": "user:sam"
  }
})

response = http.request(request)
puts response.read_body

# Response: {"allowed":true,"resolution":""}
```

<div class= "alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
<strong>You can check out the <a href= "https://play.fga.dev/sandbox/?store=expenses">Auth0 FGA Playground</a> for more info about this concrete example as well as other useful examples for you to learn more about FGA.</strong>
</div>

Some advantages of using a third-party service like Auth0 FGA to manage your authorization system is that you remove the authorization logic from your application code and make sure all your policies are in one place, making it easier to maintain. You also minimize the latency in your requests because Auth0 FGA is optimized for reliability and low latency at a high scale, and in your specific case, you'll reduce latency even more because you won't be hitting your database every time you want to check if a user can approve an expense report. 

When you finish implementing your authorization model, you go back to your stakeholders and show them your progress; they are thrilled! 🥳 They like the progress you've made. Still, now they decided they want to have a [git-like](https://git-scm.com/) system where you can have multiple versions of the same report, branches, and teams, and you take another deep breath 🧘 and proceed to explain that this will move the initial deadline, and so the drama continues...

<include src="SmallBannerCTA" text="Want to take your Authorization to the next level? → " linkText="fga.dev" link="https://a0.to/oktafga_blog" imgLink="https://cdn.auth0.com/website/blog/banners/fga.png" imgAlt="Okta FGA Logo" />

## Conclusion 

Authorization models give you the structure and rules for deciding who can access what in your application. Depending on your use case, one model can be better than another. Or you may end up using multiple models to serve your needs, depending on the complexity of your use case. 

You almost always want to have authentication in your system, but it's usually not enough for users to be authenticated to verify if they have access to a resource or not. A Role-Based Access Control (RBAC) model might be enough for simple applications, especially if you have a few roles. However, the more granularity you want in your access control model, you might consider using permissions and assigning them to users regardless of their roles. You might define the access control based on some of your user's attributes, for example, by implementing ABAC, or you can restrict access to resources based on your object relationships using ReBAC. Whatever your requirement is, Auth0 and Auth0 FGA offer you a solution that can be used to address your authorization needs at scale in a progressive manner.

What's the Right Authorization Model for My Application?

5e074956ee8ba1fea26e30d28c190495?s=300 avatar

5e074956ee8ba1fea26e30d28c190495?s=300

Full stack developer creating content at Auth0. I love taking a deep dive into hard-to-understand concepts and creating content that makes them easier to grasp. In my free time you can usually find me reading, hanging out with my dogs, or curling in the squat rack.

Former Developer Content Manager

Holly Guevara

Build a Flask and GraphQL quidditch management system that uses Auth0 rules to implement ABAC and GBAC.

"abac"