tyler-nix

Tyler’s professional experience spans engineering, architecture, sales, and product at companies ranging from a small Series B startup to a large Fortune 5 enterprise. He now uses his diverse experiences to build better products at Okta. When he is not scaling digital products, he is pursuing hobbies that inherently don’t scale (especially those outside). He loves hearing his kids laugh while riding bikes, spotting a new bird species, and watching his garden grow.

Product Manager

Tyler Nix

Learn how the ReBAC authorization model overcomes RBAC when it comes to evaluate permissions on a specific resource.

In today’s dynamic digital landscape, ensuring users have the right permissions for specific resources is a critical task for any organization. Resource-based access control often needs to be highly fine-grained, especially in complex systems with millions of objects—such as files, projects, records, accounts, etc.

Yet building fine-grained authorization (FGA) correctly with traditional Role-Based Access Control (RBAC) presents several challenges, particularly when it comes to protecting against the top vulnerability in web applications: [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/).

RBAC itself isn't inherently problematic. But when you try to build fine-grained authorization on top of RBAC, the struggle creeps in. However, this is where Relationship-Based Access Control (ReBAC) shines: evaluating permissions on a per-resource basis. ReBAC makes it simple to perform an authorization check on complex permission models.

## The Difficulty of Building Fine-Grained Authorization with RBAC

[RBAC](https://auth0.com/docs/manage-users/access-control/rbac) has been the go-to method for managing access control in many applications. In RBAC, users are assigned to roles (e.g., admin, editor, viewer), and roles are mapped to permissions that give access to various resources.

A common approach to evaluating access to a resource in an application is to include the permissions in a user’s access token as scopes. However, since most scopes are generic and binary (e.g. `_view_all_documents_`), it would be difficult to manage detailed, resource-specific scopes (e.g. _view_document_123_) by adding them to the token because it would lead to token bloat. Additionally, since scopes in a token are static by design, they cannot easily reflect real-time permission updates until the token is refreshed.

Because of this, developers will often implement their own custom FGA solutions using RBAC built with SQL tables to unlock more dynamic and real-time access control. But this approach isn’t without its issues.

As systems grow and product improvements require more intricate resource hierarchies, the need to manage numerous roles, users, and resource-specific permissions leads to messy databases and unruly SQL queries, which often involve multiple joins spread out across database tables or services.

In contrast, [(ReBAC)](https://docs.fga.dev/authorization-concepts#what-is-relationship-based-access-control) models permissions based on relationships between users and resources, simplifying the evaluation logic. With ReBAC, permissions are dynamic and context aware. While you can fully implement RBAC roles within ReBAC, it also allows for more granular control over who can do what with each resource.

## Evaluating Resource-Specific Permissions with RBAC

Let’s consider an example: In a project management application, Aria is the admin for her entire organization. She is thus granted permissions to view and edit all documents in any project. The developers of the application have chosen to implement resource-specific authorization by building RBAC in SQL tables.

How do we determine if Aria has access to view a specific document? She would not have any direct assignments because she is not the document creator, but she should inherit the “editor” permissions since she is the organization’s admin. Evaluating this resource-specific authorization check in RBAC would require joining the various database tables that contain the role assignments and resource hierarchies in the organization to see if her "admin" role cascades down to that specific document.

As a result, with each permission check requiring more complex SQL queries, the application’s authorization logic becomes difficult to manage and even harder to update, possibly even leading to performance issues with deeply nested resources.

## How ReBAC Simplifies Resource-Specific Permission Checks

With ReBAC, permissions are calculated based on relationships instead of explicitly assigned roles, simplifying the evaluation of who has access or not. In a ReBAC system, Aria’s permissions aren’t solely based on her role but also on her role’s relationships with a document. Since Aria is the admin of the organization, the relationship can be cascaded down from the organization level via inheritance to a specific project or document level.

When you need to make an authorization check on a specific resource, the authorization system references the logic defined in the authorization model against the known object relationships and returns a decision (i.e. true or false). “_Can Aria edit the document business-report-1?_” = TRUE. We’ll learn later why this authorization check can be so simple.

> ReBAC makes it far more efficient than RBAC to check access on a per-resource basis.

## Evaluating Permissions with Okta Fine Grained Authorization

Now, let’s explore how Okta Fine Grained Authorization, a hosted and managed service of the popular open-source ReBAC project OpenFGA, leverages relationship-based access control to simplify access management.

Okta Fine Grained Authorization is designed to be flexible enough to work for small startups scaling single applications but powerful enough for large enterprise corporations creating complex relationships at a global scale. It does all of this while staying friendly enough for adjacent stakeholders on the team to read and understand the authorization logic.

Let’s build on the practical example above of Aria being an admin in her project management company. Suppose you have a hierarchical system in which different teams have access to various documents in a project based on the user's assignment.


### Sample Authorization Model in Okta Fine Grained Authorization

```bash
model
   schema 1.1

type user

type organization
  relations
    define admin: [user]

type project
  relations
     define organization: [organization]
     define owner: [user] or admin from organization
     define member: [user]
     define viewer: member or owner

type folder
  relations
     define parent: [folder, project]
     define owner: owner from parent
     define viewer: viewer from parent or owner

type document
  relations
     define parent: [folder]
     define editor: [user] or owner from parent
     define viewer: [user] or viewer from parent or editor
```

In this model, there are five core “types”: `user`, `organization`, `project`, `folder`, and `document`. Each plays a specific role in managing access within the system.

- `User` represents the individuals who will interact with the system. Users are assigned roles and permissions either directly or through group memberships.
- `Organization` contains all the projects with the ability to assign a global admin (like Aria).
- `Project` contains members, controlling access to project documents through membership at a top-level project.
- `Folder` adds a hierarchy to managing resources, connecting users to documents, even through deeply nested folders.
- `Document` inherits access permissions from their parent folder, which ultimately inherits from the project, all while allowing direct assignment to enable use cases like sharing a document with an external user.

A typical authorization scenario might look like this:

1. _Document_ business-report-1 is nested inside two _Folders_ under _Project_ Alpha.
2. _Project_ Alpha is a part of the Acme _Organization_.
3. Aria is assigned as the admin of the Acme _Organization_.

In Okta Fine Grained Authorization, these would be represented as relationship tuples stored in the centralized authorization system. You can think of Okta Fine Grained Authorization as a permissions database and tuples are the data. Each tuple will contain a user, relation, and object value like this:

```bash
{
  User: user:aria
  Relation: admin
  Object: organization:acme
}
```

Thus, following the logic in the authorization model, the access check for _“Can Aria edit the document business-report-1?”_ would return TRUE because:

1. Aria has the admin relationship in the Acme organization.
2. The admin relationship receives the owner relationship in the projects of that organization.
3. The owner relationship is thus inherited by the folders in that project.
4. Owner permissions continue to cascade down to the editor relationship of the documents inside the organization’s project folder, of which Aria is the admin.

![](https://images.ctfassets.net/23aumh6u8s0i/3pEKrtX5hEZrGMz2mT40RV/d13f7730b526aec43508c1f1294b37e3/01_rebac.png)

![](https://images.ctfassets.net/23aumh6u8s0i/65WRfIj3zGTtCo8S5dimhn/e8150eab044f6763069ff81cb42bf5c7/02_rebac.png)

## The Okta Fine Grained Authorization API

With ReBAC and Okta Fine Grained Authorization, querying permissions is as simple as checking a user’s relationship to a resource. Instead of performing multiple joins across tables as in RBAC, a single API call checks the relationship, making it highly efficient.

```bash
curl -X POST https://api.fga.dev/stores/{store_id}/check \
  -H "Authorization: Bearer {your_api_token}" \
  -d '{

    "tuple_key": {
        "user": "user:aria",
        "relation": "editor",
        "object": "document:business-report-1"
      }
}'
```

While RBAC is a powerful model for role-based permissions, it can struggle when adapted to manage fine-grained, resource-specific permission scenarios. Alternatively, ReBAC excels in dynamic, heavily-nested environments where permissions are based on inherited relationships between users and resources. By adopting ReBAC (and using a platform like Okta Fine Grained Authorization), development teams can streamline how they handle complex access control in their applications, reducing the major risk of broken access control that can stem from complex database queries. Try [Okta Fine Grained Authorization](https://auth0.com/fine-grained-authorization) for free.

### Additional Resources

- [https://fga.dev](https://fga.dev/)
- [FGA Playground](https://play.fga.dev/)
- [Fine-Grained Authorization in your Next.js application using Okta FGA](https://auth0.com/blog/fine-grained-access-control-with-okta-fga-nextjs/)
- [FGA Modeling Guide Video Series](https://www.youtube.com/watch?v=8VGy52SQ8bw)

How To Evaluate Resource-Specific Permissions Efficiently with ReBAC instead of RBAC

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

Staff Developer Advocate

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

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.

Principal Developer Advocate

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.

```
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. 

```REGO
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:

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

```
{
  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`.

```
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
```

```
{
  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

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, Python, and Elixir.  

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. 

Senior Developer Advocate

Carla Urrea Stabile

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

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

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?

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.

Andrea Chiarelli

Learn how to use roles in your Blazor Server and WebAssembly applications to implement the RBAC authorization model.

Role-Based Access Control in Blazor Applications

What is the best way to apply Role-Based Access Control (RBAC) to your ASP.NET Web API? Let's find out together.

Role-Based Authorization for ASP.NET Web APIs

matthew-casperson

Technology enthusiast since my first C64. I love writing about new ideas and working with great people.

Product Manager at Octopus Deploy

Matthew Casperson

Learn how to add Auth0 RBAC authorization to Ktor HTTP API endpoints

In the previous post, we created an Auth0 API to represent the Ktor HTTP API and an Auth0 application to allow the frontend application to authenticate users. This allowed us to query the backend API from the frontend application with a valid access token. We also updated the backend API to require a valid access token for the `protected` and `admin` endpoints.

In this post, we'll complete the journey by enabling Role-Based Access Controls (RBAC) within Auth0 and restrict access to the `admin` endpoint in our backend API to those users with the correct permissions.

## RBAC and permissions

We start by enabling RBAC within our Auth0 API.

Under the **Settings** tab in the API, switch the **Enable RBAC** and **Add permissions in the Access Token** sliders to the on the setting. Doing so will ensure a `permissions` claim is added to the access token with any scopes that have been assigned to the logged-in user.

A detailed discussion on why scopes should not be used to grant permissions is presented in the post [On The Nature of OAuth2's Scopes](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/). The summary is that a scope constrains the actions that an OAuth client *may* attempt to perform on behalf of a user, but *does not* imply that the user has the permission to access any particular resource.

This has some subtle but significant implications on the claims returned in an Auth0 access token.

Without enabling the RBAC settings, any scope requested by the OAuth client and consented to by the user will be returned in the `scope` claim. It doesn't matter if that scope has been assigned to the user or not - it is returned regardless. It is then the responsibility of the OAuth resource server to allow or deny access to a given resource based on the user's identity and the action being performed.

When RBAC is enabled, only scopes that have been requested by the client, *and* consented to by the user, *and* assigned to a user will be returned in the `scope` claim. In this scenario, the resource server can assume the absence of a scope means the client did not request it, the user did not consent to it, or it has not been assigned to the user, and so can quickly deny access.

By adding the `permissions` claim, each scope assigned to the user is calculated and included in the access token. The `permissions` claim is populated without asking for consent from the user, which supports more traditional RBAC style applications, where clients have delegated all the permissions of their users, and the users don't pick and choose scopes with each login.

Our sample application will make use of the scopes in the `permissions` claim to determine access to the API.

![RBAC](https://images.ctfassets.net/23aumh6u8s0i/4ZpaxCFDvKa7It8aToFSBP/06e7bd6600e3146032475a399a0d068a/01_build-a-ktor-api-pt-3.png)
_Enabling RBAC and permissions in the access token._

Under the **Permissions** tab, define a new **Permission (Scope)** of `read:admin-messages` and a **Description** of **The ability to access the admin endpoint**. Click the **Add** button to save the new permission:

![API](https://images.ctfassets.net/23aumh6u8s0i/1DJaaadYXA4vGKV9i9R8LK/4564b6449b1b1d190f2345638431b92d/02_build-a-ktor-api-pt-3.png)
_Creating an API permission._

### Creating the role

We now create a role to hold the permissions required by our API. Click the **User Management -> Roles** option and click the **Create Role** button.

In the **New Role** dialog, enter a name of **messages-admin**, enter a description, and click the **Create** button:

![Roles](https://images.ctfassets.net/23aumh6u8s0i/7EQTp4sJS03bScEWno7kEa/a1c2586b32a480c4b166fb4ce5ba09b5/03_build-a-ktor-api-pt-3.png)
_Creating a new role._

Under the **Permissions** tab click the **Add Permissions** button. In the **Add Permissions** dialog select the API we created earlier, select the **read:admin-messages** permission, and click the **Add Permission** button:

![Permissions](https://images.ctfassets.net/23aumh6u8s0i/ZBB0FviUiLxmOzXoeDvJV/20ce7562521525551515e16e1c23bbe2/04_build-a-ktor-api-pt-3.png)
_Adding permissions to a role._

### Assigning the role to a user

For the purposes of this demo, I'll assume you have already [created an Auth0 user](https://auth0.com/docs/users/create-users). I'll also assume this user is linked to the application that was created earlier.

Select the user, click the **Roles** tab, and click the **Assign Roles** button.

In the **Add Roles** dialog, select the **messages-admin** role and click the **Assign** button:

![User](https://images.ctfassets.net/23aumh6u8s0i/6X6s3poUPbop1eG6LShtqM/b8147045f0f291e2e853b6f8027a1e74/05_build-a-ktor-api-pt-3.png)
_Assigning a role to a user._

Auth0 is now configured and ready to authenticate our frontend application. We can move on to updating our Ktor HTTP API to check for the presence of these permissions when accessing the `admin` endpoint.

<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" />

## The sample application code

To build the backend application, you'll need to have JDK 11 or above, which is available from many sources, including [OpenJDK](https://openjdk.java.net/install/), [AdoptOpenJDK](https://adoptopenjdk.net/), [Azul](https://www.azul.com/downloads/), or [Oracle](https://www.oracle.com/au/java/technologies/javase-jdk11-downloads.html).

The final code for the Ktor application can be found [here](https://github.com/mcasperson/Auth0Ktor). The code discussed in each post is matched by a branch:

* [starter](https://github.com/mcasperson/Auth0Ktor/tree/starter) - the base API with no authentication or authorization.
* [add-authorization](https://github.com/mcasperson/Auth0Ktor/tree/add-authorization) - the API requiring a valid access token for the `protected` and `admin` endpoints. 
* [add-rbac](https://github.com/mcasperson/Auth0Ktor/tree/add-rbac) - the API requiring special permissions to access the `admin` endpoint. This branch is discussed in this post.

The frontend application code can be found [here](https://github.com/auth0-sample-gallery/spa_react_javascript_hello-world).

## Updating the API

The backend API must now be updated to ensure the `admin` endpoint requires the access token, including the `read:admin-messages` permission. The complete code for the `src/Application.kt` file is shown below:

```kotlin
package com.matthewcasperson

import com.auth0.jwk.JwkProviderBuilder
import io.ktor.application.*
import io.ktor.auth.*
import io.ktor.auth.jwt.*
import io.ktor.features.*
import io.ktor.http.*
import io.ktor.response.*
import io.ktor.routing.*
import java.util.concurrent.TimeUnit

fun main(args: Array<String>): Unit = io.ktor.server.netty.EngineMain.main(args)

fun validateCreds(credential: JWTCredential, permission: String? = null): JWTPrincipal? {
    val containsAudience = credential.payload.audience.contains(System.getenv("AUDIENCE"))
    val containsScope = permission.isNullOrBlank() ||
            credential.payload.claims["permissions"]?.asArray(String::class.java)?.contains(permission) == true

    if (containsAudience && containsScope) {
        return JWTPrincipal(credential.payload)
    }

    return null
}

fun Application.module() {

    val jwkProvider = JwkProviderBuilder(System.getenv("ISSUER"))
        .cached(10, 24, TimeUnit.HOURS)
        .rateLimited(10, 1, TimeUnit.MINUTES)
        .build()

    install(Authentication) {
        jwt("auth0") {
            verifier(jwkProvider, System.getenv("ISSUER"))
            validate { credential -> validateCreds(credential) }
        }
        jwt("auth0-admin") {
            verifier(jwkProvider, System.getenv("ISSUER"))
            validate { credential -> validateCreds(credential, "read:admin-messages") }
        }
    }
    install(CORS) {
        anyHost()
        method(HttpMethod.Options)
        method(HttpMethod.Get)
        header("authorization")
        allowCredentials = true
        allowNonSimpleContentTypes = true

    }


    routing {
        get("/api/messages/public") {
            call.respondText(
                """{"message": "The API doesn't require an access token to share this message."}""",
                contentType = ContentType.Application.Json
            )
        }
    }

    routing {
        authenticate("auth0") {
            get("/api/messages/protected") {
                call.respondText(
                    """{"message": "The API successfully validated your access token."}""",
                    contentType = ContentType.Application.Json
                )
            }
        }
    }

    routing {
        authenticate("auth0-admin") {
            get("/api/messages/admin") {
                call.respondText(
                    """{"message": "The API successfully recognized you as an admin."}""",
                    contentType = ContentType.Application.Json
                )
            }
        }
    }
}
```

Let's highlight the changes required from the code presented in the previous blog post.

We've updated the `validateCreds` function to include an optional `permission` parameter. If a permission has been supplied, we ensure it is present in the `permissions` claim on the access token:

```kotlin
fun validateCreds(credential: JWTCredential, permission: String? = null): JWTPrincipal? {
    val containsAudience = credential.payload.audience.contains(System.getenv("AUDIENCE"))
    val containsScope = permission.isNullOrBlank() ||
            credential.payload.claims["permissions"]?.asArray(String::class.java)?.contains(permission) == true

    if (containsAudience && containsScope) {
        return JWTPrincipal(credential.payload)
    }

    return null
}
```

We then define a second authentication mechanism called `auth0-admin` requiring the permission `read:admin-messages` in order to pass validation:

```kotlin
    install(Authentication) {
        // ...
        jwt("auth0-admin") {
            verifier(jwkProvider, System.getenv("ISSUER"))
            validate { credential -> validateCreds(credential, "read:admin-messages") }
        }
    }
```

Finally, the route exposing the `admin` endpoint is updated to use the new `auth0-admin` authentication mechanism:

```kotlin
    routing {
        authenticate("auth0-admin") {
            get("/api/messages/admin") {
                call.respondText(
                    """{"message": "The API successfully recognized you as an admin."}""",
                    contentType = ContentType.Application.Json
                )
            }
        }
    }
```

## Inspecting the access token

By capturing the network traffic sent by the frontend (as we did in the previous post), we can copy the access token to [jwt.io](https://jwt.io) to inspect the JWT contents.

Note that the token includes the `permissions` claim, which defines the `read:admin-messages` permission:

![Inspecting the access token](https://images.ctfassets.net/23aumh6u8s0i/eFammxKcqhwLSKDPgfxRU/8b24e9b2c662143d983b4033aef61197/Assigning_the_role_to_a_user.jpg)
_A parsed JWT token._

## Conclusion

In this post, we completed our three-part journey creating an HTTP API with Ktor, requiring authentication via Auth0, and finally enabling RBAC. By embedding the permissions assigned to a user in the `permissions` scope and verifying the presence of a known permission for any queries to the `admin` endpoint, we can be sure that only authorized users can access the restricted endpoints in our HTTP API.

"rbac"