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. 

Senior Developer Advocate

Carla Urrea Stabile

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 

Most applications start with a need for tenant-level permissions. How do you control what users can do within their own organization? Let's learn how to implement RBAC in a FastAPI Application and OpenFGA to manage multi-tenancy.

Implementing Role-Based Access Control (RBAC) with Auth0 FGA and FastAPI

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

william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

Learn about Relationship-Based Access Control (ReBAC): how it works, its benefits for flexible authorization, and how Auth0 FGA helps implement it effectively.

You know how on a git repository your permissions feel so intuitive? You're not just a generic 'user' across the whole application. You might be the owner of your own repo, a maintainer with merge rights on a team project, and only have permission to help organize the bug reports and feature requests on an open-source library you contribute to.

This whole system, where your permissions change based on your specific connection to a repo, a pull request, or an organization is the core idea behind Relationship-Based Access Control (ReBAC). It’s an authorization model based on how users work together. Access is defined by your relationship to the resource and not just what role you’re assigned.

ReBAC isn't the only choice for access control. It's one tool in a toolbox that includes other models like [RBAC](https://auth0.com/docs/manage-users/access-control/rbac) and [ABAC](https://auth0.com/blog/what-is-abac-and-how-to-implement-it-rails-api/#What-Is-Attribute-Based-Access-Control--ABAC--). As a developer, you might then ask, 'Which one is the right tool for my job?'"

To help you navigate that choice, we've put together a detailed post on [how to choose the right authorization model for your SaaS application.](https://auth0.com/blog/how-to-choose-the-right-authorization-model-for-your-multi-tenant-saas-application/)

## Understanding How ReBAC Systems Function

A ReBAC system is built on three main concepts that link together, which we'll break down using a git repository as our example.

**1. Subjects in a ReBAC System**

First up, you have the "Subject." This is the person or service that's trying to do something.

*Example:* A developer's account, `user:jane-doe`.

*Example:* An automated service, like `service-account:git-actions`.

**2. Objects: the Resources Controlled by ReBAC**

Next, there's the "Object." This is the resource the Subject wants to interact with or change.

*Example:* A whole repository, like `repo:acme-corp/webapp`.

*Example:* A specific pull request, like `pr:123`.

**3. Relationships: the Core of ReBAC**

Finally, and most importantly, you have the "Relationship." This is the piece that connects a subject to an object. It’s a simple, stored fact that describes their association. This isn't the permission itself, but a label defining the connection.

These relationships come in two main types:

* A **direct relationship** is a simple, stored fact, like a direct assignment.

*Example:* `user:jane-doe` is a maintainer of `repo:acme-corp/webapp`.


* An **indirect relationship** is where the system connects the dots for you. This is often called inherited permission.

*Example:* Dave gets `write_access` to a repo indirectly simply because he's a member of a team that has that access.

## How Does ReBAC Grant Permissions?

So if the relationship isn't the permission, how is a decision actually made? The system uses a separate set of rules that it checks against the facts.

Let's walk through a real git repository scenario:

* **The Ask:** Jane (`user:jane-doe`) tries to merge a pull request into the main branch of the `acme-corp/webapp repo`.

* **The System Checks:** The system doesn't ask, "Is Jane an admin?" Instead, it asks, "How is Jane connected to this specific repo?"

* **It Finds a Fact:** The system sees the stored fact: (`user:jane-doe`, `maintainer`, `repo:acme-corp/webapp`).

* **It Checks the Rulebook:** The repository's rules say something like: "Anyone with the maintainer relationship is allowed to `merge_pull_request`."

* **The Result:** The fact matches the rule, and the merge is allowed.

The power of this model is its flexibility. It means you can tweak your enforcement rules in GitHub (like requiring two reviews before merging) at any time, without having to go back and change the underlying relationship facts for all your developers.

## Challenges of Implementing ReBAC in Your Authorization System

Thinking about using ReBAC? Here's a quick heads-up on the common challenges you might run into.

### Performance Considerations for Scaling ReBAC

To check one permission, a ReBAC system might have to look up several different relationships that connect together. For example, checking if a user can see a file might involve checking their team memberships, which in turn involves checking the team's parent organization, and so on.

This can sometimes lead to slow queries and performance hits. As your application grows, it takes lots of engineering work to keep those lookups from slowing everything down.

### Designing Effective ReBAC Models

What makes ReBAC so great is its flexible, graph-style structure, but that's also what makes it tricky. The complexity isn't in a long list of rules, but in the designing of the relationship model itself.

Figuring out the "right" way to model your permissions (e.g., should a manager automatically inherit the permissions of everyone on their team?) is a big deal to start with. A poorly designed model can be hard to understand and even harder to change later on.

### Ensuring Audibility in Complex ReBAC Models

A side effect of a complex model is that auditing permissions can be tough. Answering a seemingly simple question like, "Why does Jane have access to this document?" can feel like untangling a ball of yarn. You might have to trace a path through five different indirect relationships involving teams and groups, which can make security reviews and debugging a pain.

### Keeping Your Data in Sync

Another roadblock you could run into is the dual-write problem. If your app's source of truth includes who's on what team or who owns what file lives in your main database and your ReBAC system is a separate service with its own database, it will need its own copy of that data to know what's going on.

And that’s how to get into the dual-write problem. When a manager moves someone to a new team, you've got to update that info in two places: your app's database and the authorization system. So, what happens if the write to your database succeeds, but the one to the auth system fails? Now you've got a user whose status is out of sync with their permissions. That can cause confusing bugs or, even worse, a security risk.

> This is a well-known problem in distributed systems If you want to see the different patterns for solving it, check out this blog post on ["Handling the Dual-Write Problem in Distributed Systems".](https://auth0.com/blog/handling-the-dual-write-problem-in-distributed-systems/)

All of these challenges point to the same advice. Using ReBAC successfully means putting in serious thought at the design stage. It trades the ongoing complexity of other systems for a thoughtful investment in your initial model.

## How Auth0 FGA Helps with ReBAC

So how do you actually use these concepts in a real tool? Let's look at [Auth0 FGA](https://a0.to/auth0-fga-content), a managed service for ReBAC. It provides the tools to get hands-on with the concepts we've been talking about and is built on the open-source [OpenFGA](https://a0.to/fga-content) (inspired by Google's Zanzibar).

Let's model our git scenario to show both direct and indirect permissions.

## Defining the ReBAC Authorization Model in Auth0 FGA

First, we define our authorization model in the Auth0 FGA Model Explorer. This is where we'll spell out the concepts we talked about earlier in the blog post. By defining the types of **objects** to be protected and the possible **relations** a **subject** can have with them. For example, a key **relation** in our model is `can_write`, which grants access if a **subject** has either a direct `maintainer` relationship with the **object**, or an indirect one by being a `member` of a `writer` team.

```js
model
  schema 1.1

type user

type team
  relations
    define member: [user]

type repository
  relations
    define maintainer: [user]
    define writer: [team]    
    define can_write: maintainer or member from writer
```

This model sets up our rule:

* A user gets `can_write` permission directly if they are a `maintainer`.
* A user gets `can_write` permission indirectly if they are a `member` of a `team` that is a designated `writer`.

## Creating Relationship Tuples in Auth0 FGA

Remember how we described a relationship as just a simple, stored fact? Now, it's time to actually store some of those facts in our system.

In the world of Auth0 FGA, each one of these "facts" is stored in something called a Tuple. Think of a Tuple as a single line-item that records one specific relationship, it's the raw data that connects a user to an object and solidifies their connection. You can use **Tuple Management** in the Auth0 FGA dashboard to add Tuples

```js
[
  // 1. Anne is a direct maintainer of the "webapp" repo
  {
    "user": "user:anne",
    "relation": "maintainer",
    "object": "repository:webapp"
  },
  // 2. The "developers" team is a writer on the "webapp" repo
  {
    "user": "team:developers",
    "relation": "writer",
    "object": "repository:webapp"
  },
  // 3. Bob is a member of the "developers" team
  {
    "user": "user:bob",
    "relation": "member",
    "object": "team:developers"
  }
]
```

### Verifying Access in Auth0 FGA

Now for the test. We ask the system simple questions, and it uses the model and the facts to give us an answer. In Auth0 FGA, we write assertions for this.

**Check #1 (Direct Relationship)**

* **Question:** Can Anne write in the "webapp" repo?
* **Answer: Yes.** The system checks the `can_write` rule. It sees that `maintainer` is a type of `can_write`, finds the fact that Anne is a `maintainer`, and grants access.

**Check #2 (Indirect Relationship)**

* **Question:** Can Bob write in the "webapp" repo?
* **Answer: Yes.** This is where the power of the model shines. 

The system checks:

1. Is Bob a direct `maintainer`? No.

2. Is Bob a `member` of a `team` that is a `writer` on this repo?

3. It finds the fact that the `team:developers` is a writer on `repository:webapp`.

4. It then checks if `user:bob` is a `member` of `team:developers`. Yes, it finds that fact.

5. The indirect rule (member from writer) is satisfied. Access granted.

Bob never got permission directly, but the system figured it out by traversing the relationship graph. If you want to get your hands dirty and build this yourself, the [Auth0 FGA documentation](https://docs.fga.dev/getting-started) is the best place to start.

You can see what each of these steps look like in Developer Mode of the Auth0 FGA playground.

![](https://images.ctfassets.net/23aumh6u8s0i/CQLIiE44n6iPLE7wP6xeo/1c02f3f14fc626d391a0b8ab8de5ab71/Screenshot_2025-06-13_at_11.57.21_AM.png)

## Final Thoughts on Relationship-Based Access Control

To bring it all together, ReBAC is an approach for modeling permissions that mirrors how your application actually works. Instead of relying on broad, static roles, it focuses on specific relationships: who owns a document, who is a member of a team, or who is assigned to a task. 

It does need more thought upfront to design that relationship model well. But the payoff for that initial work is an authorization system that's ultimately easier to use and change. When your app's features change, you often end up adding new relationships rather than rewriting hard-coded permission logic.

[Auth0 FGA](https://a0.to/auth0-fga-content) is a tool that provides the high-performance infrastructure for this approach, but the essential first step is always the work of designing a solid model that fits your application's needs.

What Is Relationship-based access control (ReBAC)?

Learn how to add Role-Based Access Control (RBAC) to your B2B SaaS application that leverages Auth0 Organizations.

In the realm of B2B SaaS, the ability to offer isolated and tailored experiences to distinct customer organizations is paramount. Auth0 Organizations provides a robust framework for managing these multi-tenant environments, offering features like dedicated user bases, custom branding, and organization-specific configurations. Building upon this foundation, implementing Role-Based Access Control (RBAC) within Auth0 Organizations unlocks a new level of granularity in managing user permissions.

In this article, we will explore how roles fit in the Auth0 Organizations framework and how to manage them programmatically using the SaaS Blazor application we are building throughout a series of articles.

## Understanding Role Management in Auth0 Organizations

Auth0 allows you to define roles and permissions to apply the [Role-Based Access Control authorization model](https://auth0.com/docs/manage-users/access-control/rbac). Usually, roles assigned to users apply across your entire Auth0 tenant. For example, a user who is assigned the _editor_ role will keep this role in all applications registered in your Auth0 tenant unless you apply a different authorization policy via [Actions](https://auth0.com/docs/customize/actions).

Auth0 Organizations allow you to represent your customers' users as distinct entities within your Auth0 tenant. This isolation is crucial for managing users, connections, and policies on a per-organization basis. In the Auth0 Organization context, roles are defined and scoped *within* a specific Organization. This crucial distinction allows for fine-grained control over what members can do *within* their designated Organization.

Consider a scenario where you have two customers using your SaaS application: Acme Inc. and Foo Corp. You used Auth0 Organizations to separate Acme Inc. users from Foo Corp. users. However, based on the [login flow you configured for your application](https://auth0.com/docs/manage-users/organizations/login-flows-for-organizations) and the [connection model](https://auth0.com/docs/manage-users/organizations/organizations-overview#connection-model) you are applying, you can have specific situations.

For example, suppose you have enabled users to log in as both an individual and an organization user. In that case, the question arises as to which role to consider. In fact, the user can be the application administrator when logging in as an individual, but a mere member when logging in as an Acme Inc. user.

Similarly, if you allow users to be shared between organizations, i.e., a user can be both an Acme Inc. and a Foo Corp. user, then there may be a need for the user to have different roles based on the Organization they are logging in to. For example, the user can be an administrator when logging in to Acme Inc. and just a member when logging in to Foo Corp.

Hence, the need for having roles linked to the Organization.

> In this article, we discuss traditional Role-Based Access Control, but in more complex B2B SaaS scenarios, you may need more granularity for your authorization check. In this case, you can leverage [Fine-Grained Authorization](https://a0.to/auth0-fga-content).

## Creating Roles for an Auth0 Organization

Creating roles to assign to users in an Auth0 Organization is straightforward. You can use your Auth0 dashboard or the Auth0 Management API. In both cases, there are two basic steps:

1. Create [the roles your application needs in your tenant](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/roles/create-roles).
2. Assign one or more [roles to the members of an Organization](https://auth0.com/docs/manage-users/organizations/configure-organizations/add-member-roles).

In this article, we will use the Auth0 Management API to create roles and assign them to the members of an Organization.

### The Sample Application

The scenario you will be using is the B2B SaaS application we built in the previous articles using Blazor. The following articles recap how we built the application:

- [Add Auth0 Organizations to Your B2B Blazor Web App](https://auth0.com/blog/auth0-organizations-for-b2b-saas-blazor-web-apps/)
- [Enable Self-Subscribing Model in Your Blazor B2B SaaS Application](https://auth0.com/blog/enable-self-subscription-in-blazor-b2b-saas-application/)
- [Enforce Customer Email Verification in Your B2B Blazor Web App](https://auth0.com/blog/enforce-customer-email-verification-b2b-saas-blazor-app/)

You can download the starting Blazor project by running the following command:

```bash
git clone --branch email-verification --single-branch https://github.com/andychiare/MyBlazorSaaS
```

Follow the instructions in the attached README file to register and configure the application with Auth0. If you don't have an Auth0 account, [you can sign up for free](https://a0.to/blog_signup).

The Blazor application allows a new customer to subscribe and create a new Organization, but currently it makes no distinction between users. We want to introduce two roles in the application:

- the *admin* role, which is automatically assigned to the user who subscribes to your application and allows them to access an admin dashboard.
- the *member* role, which can be assigned to users who can't access the admin dashboard.

> In this example, you do not use permissions, which are typically assigned to roles. To keep things simple, you are focusing on role names to make access control.

<include src="Auth0TemplatesForDotnetCTA" />

### Creating the roles for the Auth0 Organization

Before modifying the application code, make sure you to update the permissions your application needs for managing roles. Assuming you have configured your application accordingly to the mentioned README file, go to your [Auth0 dashboard](https://manage.auth0.com/) and locate the *ManagementClient* application in the [Applications > Applications](https://manage.auth0.com/#/applications) section.

Select the *APIs* tab of the application's configuration page and expand the area below the Auth0 Management API item. Then, select the following permissions to add them to the existing ones:

`read:roles`, `create:roles`,  `update:organizations`, `create:organization_member_roles` , and `read:organization_member_roles`.

Finally, click the *Update* button to apply your changes.

Now you can proceed to make the changes that allow the application to create the *admin* and *member* roles if they have not been created previously. The *admin* role will be assigned to the newly created user within the new Organization.

For this purpose, open the `CreateOrganization.razor` file in the `MyBlazorSaaS/Components/Pages/Onboarding` folder and apply the changes highlighted below:

```csharp


//...existing code..
  
  private async Task StartCreateOrganization()
  {
    if (!String.IsNullOrEmpty(OrganizationName))
    {
      Organization organization;

      try {
        //...existing code...

        // 👇 new code
        //Create admin role if it does not exist
        Role adminRole;
        var adminRoleList = await managementClient.Roles.GetAllAsync(
          new GetRolesRequest {NameFilter = "admin"}
          );

        if (adminRoleList.Count == 0)
        {
          adminRole = await managementClient.Roles.CreateAsync(
            new RoleCreateRequest
            {
              Name = "admin",
              Description = "Manage the organization's configuration."
            }
          );
        } else {
          adminRole = adminRoleList[0];
        }

        //Create member role if it does not exist
        Role memberRole;
        var memberRoleList = await managementClient.Roles.GetAllAsync(
          new GetRolesRequest {NameFilter = "member"}
          );

        if (memberRoleList.Count == 0)
        {
          memberRole = await managementClient.Roles.CreateAsync(
            new RoleCreateRequest
            {
              Name = "member",
              Description = "Member of an organization."
            }
          );
        } else {
          memberRole = memberRoleList[0];
        }
        // 👆 new code

        //Add member
        await managementClient.Organizations.AddMembersAsync(
          organization.Id,
          new OrganizationAddMembersRequest() {
            Members = [UserId]
          }
        );

        // 👇 new code
        //Assign admin role to the new member
        await managementClient.Organizations.AddMemberRolesAsync(
          organization.Id,
          UserId,
          new OrganizationAddMemberRolesRequest {
            Roles = [adminRole.Id]
          }
        );
        // 👆 new code

        //...existing code...
    } else {
      Message = "Organization name is required.";
    }    
  }

//...existing code...
```

The first code block creates the two roles if they already don't exist. The second code block assigns the admin role to the user in the context of the current Organization. Let's take a closer look at the code:

```csharp
        //Create admin role if it does not exist
        Role adminRole;
        var adminRoleList = await managementClient.Roles.GetAllAsync(
          new GetRolesRequest {NameFilter = "admin"}
          );

        if (adminRoleList.Count == 0)
        {
          adminRole = await managementClient.Roles.CreateAsync(
            new RoleCreateRequest
            {
              Name = "admin",
              Description = "Manage the organization's configuration."
            }
          );
        } else {
          adminRole = adminRoleList[0];
        }
```

This part creates the *admin* role. It defines the `adminRole` variable and uses the `GetAllAsync()` method of the `Roles` object to get the *admin* role from your Auth0 tenant. Notice the filter passed as a parameter to get just the role named `admin`.

> Check out the [Management API reference documentation for more details on role management](https://auth0.github.io/auth0.net/api/Auth0.ManagementApi.Clients.RolesClient.html). 

If the *admin* role does not exist in your Auth0 tenant yet, you create it using the method `CreateAsync()` of the `Roles` object. In this case, you pass a `RoleCreateRequest` instance with the role's name and a description.

If the *admin* role already exists in your Auth0 tenant, you simply assign it to the `adminRole` variable.

Similarly, you create or get the *member* role with the rest of the code.

> You may choose to [create roles for your SaaS application using the Auth0 dashboard](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/roles/create-roles). In this case, you do not need the code shown above; you only need to retrieve the *admin* role and then assign it to the user you are about to create.

After creating the user for the new Organization, you assign them the *admin* role with the following code:

```csharp
        // 👇 new code
        //Assign admin role to the new member
        await managementClient.Organizations.AddMemberRolesAsync(
          organization.Id,
          UserId,
          new OrganizationAddMemberRolesRequest {
            Roles = [adminRole.Id]
          }
        );
        // 👆 new code
```

You used the `AddMemberRolesAsync()` method of the `Organizations` object by passing the Organization ID, the user ID, and the role ID embedded in an `OrganizationAddMemberRolesRequest` instance. Read the [documentation reference](https://auth0.github.io/auth0.net/api/Auth0.ManagementApi.Clients.IOrganizationsClient.html#Auth0_ManagementApi_Clients_IOrganizationsClient_AddMemberRolesAsync_System_String_System_String_Auth0_ManagementApi_Models_OrganizationAddMemberRolesRequest_System_Threading_CancellationToken_) to learn more about the parameters of the method.

Your B2B SaaS application now has users and roles for its Organizations.

## Applying Role-Based Access Control

Once you have role support in the context of the Organizations, it's time to leverage them to control access to your application.

### Building and protecting the dashboard

As mentioned earlier, we will allow admin users to access a dashboard while Organization members will not.

Create a `Dashboard` folder in the `MyBlazorSaaS/Components/Pages` folder and add a `Home.razor` file with the following content:

```csharp


@page "/dashboard"
@attribute [Authorize(Roles = "admin")]

@inject IAuth0Management auth0Management

<PageTitle>Dashboard</PageTitle>

<h1>Welcome to your dashboard!</h1>

<div>
  <div class="form-group row my-2">
    <label for="organizationName" class="col-sm-4 col-form-label">Organization</label>
    <div class="col-sm-6">
      <InputText 
        type="text"
        @bind-Value="OrganizationName"
        id="organizationName"
        class="form-control"
        disabled/>
    </div>
  </div>
</div>

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string OrganizationName = "";

  protected override async Task OnInitializedAsync()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;

      if (state.User?.Identity?.IsAuthenticated??false)
      {
        var organizationId = state.User?.FindFirst(c => c.Type == "org_id")?.Value??String.Empty;
        if (!string.IsNullOrEmpty(organizationId))
        {
          var managementClient = await auth0Management.getClient();
          var organization = await managementClient.Organizations.GetAsync(organizationId);
          OrganizationName = organization.DisplayName;
        }
      }
    }
  }
}
```

This code defines a page that simply shows the Organization name in a readonly textbox. Notice the `Authorize` attribute at the beginning of the Razor component. It specifies "admin" as the user role authorized to access this page.

Now, open the `Home.razor` file in the `MyBlazorSaaS/Components/Pages` folder and add the markup highlighted below:

```html




@if (!string.IsNullOrWhiteSpace(OrganizationMessage)) {
  <div class="alert alert-success" role="alert">
    @OrganizationMessage
  </div>
}


<AuthorizeView Roles="admin">
    <Authorized>
      <div class="text-center">
        <p>Manage your Organization</p>
        <a href="Dashboard">Dashboard</a>
      </div>
    </Authorized>
</AuthorizeView>



```

The `AuthorizeView` component shows the dashboard link only to users with the admin role.

### Making roles available to your Blazor app

One little step is missing to get role support working in your B2B SaaS Blazor application. You need to create an [Auth0 Action](https://auth0.com/docs/customize/actions) that handles the [Post Login trigger](https://auth0.com/docs/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger) by adding the user's roles to the ID token.

Read [this article to learn the details about making roles available to your Blazor application](https://auth0.com/blog/role-based-access-control-in-blazor-apps/#Making-Roles-Available-to-the-Application).

Basically, the Auth0 Action you need to create has the following code:

```javascript
exports.onExecutePostLogin = async (event, api) => { 
  const roleClaim = 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role';

  if (event.authorization) { 
    api.idToken.setCustomClaim(roleClaim, event.authorization.roles);
  }
}
```

Make sure to deploy and add your Action to the login flow. Read [this article for an introduction to Auth0 Actions](https://auth0.com/blog/introducing-auth0-actions/).

## Testing Role-Based Access Control in Your Organization

Now it's time to test your Blazor application to ensure that users access it based on their assigned roles.

### Testing as an Organization admin

Run the application and create a new Organization by clicking the *Subscribe* link in the upper right corner of the home page. The newly created user will be assigned the admin role, so after the Auth0 Organization is created, your home page should look like the following picture:

![Blazor B2B SaaS application home page with a link to manage the organization for admin users](https://images.ctfassets.net/23aumh6u8s0i/2sHsCL5X0Jef40upiskLQ5/d57fa0a8511a4f4a7f52e18d77a598ec/homepage-admin-access.png)

Notice the link "Manage your Organization" in the center of the page. Navigating that link, you will see the following page:

![Admin dashboard in a Blazor B2B SaaS application showing the organization name](https://images.ctfassets.net/23aumh6u8s0i/XwvP3tm9SzdyMMlpRh7Do/5ddcd30334cb4ac6e75fd3384799e33b/blazor-app-admin-dashboard.png)

As an admin in the current Organization, you can access the application's dashboard.

### Testing as an Organization member

Now, log out of the application and [add a member to the Organization using the Auth0 dashboard](https://auth0.com/docs/manage-users/organizations/configure-organizations/assign-members) and [assign the member role](https://auth0.com/docs/manage-users/organizations/configure-organizations/add-member-roles). You will learn how to add a member to an Organization through your application's dashboard in a future article.

If you log in to your Blazor app as a member user, you'll get the following home page:

![Home page of a Blazor B2B SaaS application for a member user, without the organization management link](https://images.ctfassets.net/23aumh6u8s0i/7qHAZhM7Ls7HZAdk565eQA/5cf22a865c4f1b6b08dc194aeeb7a88d/homepage-member-access.png)

As an Organization member, you will not see the link to access the application dashboard.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Recap

In this article, we walked through setting up Role-Based Access Control (RBAC) for a B2B SaaS Blazor application using Auth0 Organizations. Basically, you learned how to create roles like "admin" and "member" using the Auth0 Management API and then assign them to users belonging to an Organization.

You also set up an Auth0 Action to add user roles to the ID token for your Blazor app.

Finally, we showed how to protect routes and content using the `Authorize` attribute and the `AuthorizeView` component based on these roles. We tested with both admin and member roles to confirm that RBAC was working, making sure only the authorized users could get into the dashboard.

You can find the final code of the sample project implemented throughout the article [here](https://github.com/andychiare/MyBlazorSaaS/tree/roles-organizations).

In a future article, we will add the ability to create new users to the dashboard. Stay tuned!

Implementing Role-Based Access Control in Your Blazor B2B SaaS Application

jess-author

Jessica Temporal is a Senior Developer Advocate at Auth0 and co-founder of the first Brazilian data science podcast called <a target='_blank' href='https://pizzadedados.com'><strong>Pizza de Dados</strong></a>. She’s the author of <a target='_blank' href='https://www.amazon.com/dp/B0CDNX6NS7/ref=sr_1_1?&_encoding=UTF8&tag=jesstempora0e-20&linkCode=ur2&linkId=efc4229f6b816609dfce4f185781d99a&camp=1789&creative=9325' ><strong>The Big Git Microbook</strong></a>, creator of <a target='_blank' href='https://gitfichas.com/en'><strong>GitFichas.com</strong></a>, and a part of <a target='_blank' href='https://www.linkedin.com/learning/instructors/jessica-temporal'><strong>LinkedIn Learning</strong></a> instructors team. Jessica helped develop the AI that identifies possible unlawful expenses from Brazilian politicians. She is part of the PyLadies initiative that works to improve diversity and inclusion in technology. In her free time, she likes to knit, play video games, use her 3D printer, and is learning to create 3D models.

Sr. Developer Advocate

Jessica Temporal

Generative AI is everywhere, and since not every user has access to all data, learn how to use retrieval-augmented generation with fine-grained authorization to ensure that private information stays private.

Build Trustworthy AI: Implementing Access Control for RAG Systems Using FGA

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

AAA (Authentication, Authorization, Accounting) helps developers secure web apps by verifying users, controlling access, and tracking actions.

Historically, the AAA framework (Authentication, authorization, and accounting) has been deeply tied to network security, particularly in the context of remote access, VPNs, and network devices. However, AAA is a conceptual framework and not a protocol itself, allowing us to apply it anywhere identity and access matter. Instead of a VPN gateway, you’re securing a web application. Instead of a network admin, it’s a customer buying shoes online. The scale gets bigger, the users are external, and the focus shifts toward balancing security and usability, but the AAA principles still fit to help us build robust, secure, and maintainable user-facing applications.

For developers, considering AAA in your design decisions means not only verifying who your users are (Authentication) but also controlling what they can do (Authorization) and tracking their actions for auditing and analytics (Accounting). This holistic approach minimizes security risks, enhances user experience, and simplifies compliance.

## A Framework to Measure Identity Platforms

A good identity platform gives you features out of the box that tackle each component of the AAA triad, transforming a simple login system into a comprehensive identity management system that meets your security and compliance requirements. User data is one of the most precious and valuable assets we handle as developers. As such, when we make the decision to delegate creating and handling the identity of our users to a third-party vendor, we need to ensure that we are getting better security, scalability, and user-centric experience than what we could build ourselves. The AAA framework is a helpful tool to assess whether an Identity-as-a-Service (IDaaS) vendor can help you build application systems that are resilient against threats, aligned with business requirements, and equipped for future growth.

In today’s competitive digital landscape, including identity and security as part of your MVP or existing product is a competitive advantage. A holistic approach to security is not just an option—it’s a necessity. However, not every player in the field can deliver the security the current security and threat landscape requires. Let’s dive into why Auth0 is a robust identity platform that meets the requirements of the AAA framework and why you should consider it as your identity solution of choice.

## Authentication

Authentication is the process of verifying a user's identity before granting access to your application. It answers the question: **"Who are you?"**

* [Seamless User Sign-Up and Login](https://auth0.com/docs/authenticate/login)
    * Auth0 offers multiple authentication methods, such as social logins, passwordless options, and multi-factor authentication (MFA). These features enable quick and secure identity verification.
* [Personable User Experience](https://auth0.com/docs/customize)
    * With customizable interfaces, Auth0 reduces barriers during sign-up and login, ensuring that the verification process is both secure and user-friendly.
* [Relevant User Journeys](https://auth0.com/docs/customize/forms)
    * Auth0 offers customization of the metadata you collect from users or creates a unique authentication journey that serves your business needs while still being secure.
* [Uncompromised Internationalization and Localization](https://auth0.com/docs/customize/internationalization-and-localization)
    * Auth0 can handle different languages across the authentication experience, allowing you to connect authentically and accurately with millions of potential customers across the globe. Auth0 adapts to your users instead of forcing users to adapt to inflexible platforms.

## Authorization

Authorization defines what actions or resources a user is allowed to access once they are authenticated. It answers the question: **"What can you do?"**

Auth0 allows developers to implement flexible yet comprehensive authorization models that fit different threat models.

* [Role-Based Access Control (RBAC)](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Role-Based-Access-Control--RBAC-):
    * Auth0 allows you to set granular permissions by assigning roles to users. This ensures that users only access the features and data relevant to their privileges.
* [Auth0 Actions](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization)
    * Actions are secure  Node.js functions that allow you to modify or complement the outcome of the decision made by pre-configured authorization policies. Developers can use Auth0 Actions to[ handle more complicated cases](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization) than is possible with role-based access control (RBAC).
* [Fine Grained Authorization](https://auth0.com/fine-grained-authorization)
    * Auth0 FGA delivers relationship-based access control ([ReBAC](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Relationship-Based-Access-Control--ReBAC-)) designed for complex authorization needs, such as restricting resource edits to team leads. As a managed service, it scales to handle millions of permission checks per second with minimal latency, eliminating the need to build and maintain custom solutions.

## Accounting

Accounting, also known as auditing, involves tracking and logging user activities within your application. It answers the question: **"What did you do?"**

* [Detailed Logging](https://auth0.com/docs/deploy-monitor/logs)
    * Auth0 maintains a comprehensive audit trail of authentication and authorization events. This detailed logging is essential for monitoring user behavior and identifying potential security incidents.
* [Usage Analytics](https://auth0.com/docs/get-started/auth0-overview/dashboard/activity)
    * The collected data helps analyze user interactions, optimize authentication flows, and ensure compliance with industry regulations. Accounting provides valuable insights into how your application is used.
* [Log Streaming](https://auth0.com/docs/customize/log-streams)
    * Auth0's log streaming service allows you to export tenant log events to a log event analysis service URL, leveraging robust data services, such as DataDog, Splunk, and Amazon EventBridge, and allowing you to react to events like password changes or new registrations with your own business logic.

## Bringing It All Together

Overlaying the AAA framework on your Auth0-powered B2C or B2B solutions ensures:

* **Enhanced Security:**
    * A multi-layered approach that not only verifies identities (Authentication) but also enforces precise access controls (Authorization) and continuously monitors user activities (Accounting).
* **Improved User Experience:**
    * While users benefit from a smooth and secure sign-up process, the detailed authorization rules and accounting measures ensure that they access the right features with confidence.
* **Operational Excellence:**
    * With robust logging and analytics, you can swiftly detect anomalies, refine your application, and maintain compliance with regulatory standards.

If you haven’t tried it already, [get started with Auth0 today](https://a0.to/get-started)!


Authentication, Authorization, and Accounting For Developers

The way to implement an authorization system depends on your application's needs. Let's explore Relationship-Based Access Control (ReBAC) and implement it in a Rails API using OpenFGA.

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

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.

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

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 how to use roles in your Blazor Server and WebAssembly applications to implement the RBAC authorization model.

Role-Based Access Control in Blazor Applications

Samuel Frank

Sam Frank is Auth0's Sr. Product Manager for new initiatives. He works within the Auth0 Lab to commercialize the team's new ideas so they're available for builders everywhere. As a former platform product manager and startup product lead, he knows the challenges that developers face when creating new apps and he leverages those experiences to focus our teams efforts delivering the next generation of identity tools.

Senior Product Manager

The Customer Identity Cloud platform can now reference NFTs as profile data and as a means to grant access.

The [Auth0 Lab team](http://labs.auth0.com/) has released a pair of [Marketplace integrations](https://auth0.com/marketplace) bringing more [Web3 capabilities](https://marketplace.auth0.com/categories/web3) to the Okta Customer Identity Cloud ecosystem. As the Web3 ecosystem matures, we’re finding that on-chain data, like NFTs (non-fungible tokens), can be used in the identity ecosystem. 

[Our integration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts) is a simple NFT fetch [Action](https://auth0.com/docs/customize/actions) that retrieves a list of NFTs the user owns. With them, you can make all sorts of IAM-based decisions. If you’re interested in the Auth0 Lab team’s continued Web3 research, come join the conversation on [Twitter](https://twitter.com/Auth0Lab) and [Discord](https://discord.gg/xkbkz9rZcD).

## NFTs in Identity and Access Management (IAM)

By now, you’ve probably heard of NFTs. If not, here [is a helpful explainer](https://www.nytimes.com/interactive/2022/03/18/technology/nft-guide.html). At their core, NFTs are digitally transferable tokens. Tokens have a long history in identity and access management. They are the keystone of authorization in many apps, primarily through the issuance of [JSON web tokens](https://jwt.io/). 

NFTs could be a big extension to token-based IAM. NFTs are flexible, secure, and easily transferable by their nature of using blockchain consensus algorithms to establish ownership and transference. Like with cryptocurrencies, only a specific private key in a wallet can prove ownership. They can help organizations manage capacity problems because you can limit the number of NFTs you mint. This scarcity helps manage supply while still allowing for a robust secondary market. This makes them ideal for ticketed events and venues, like stadiums, trains, and other physically limited spaces.

One of the biggest barriers to mainstream NFT adoption is the usability hurdle of working with blockchains. With our latest integrations, Auth0 Lab seeks to make it easy. Developers can query a user’s NFTs and incorporate them as identity data in their applications, even controlling access based on a user’s ownership of an NFT. We’re excited to see how developers use these new tools when implementing web3 functionality into their applications.

## Token Gating

[Token Gating](https://tokenizedhq.com/token-gating/) is the practice of managing access to resources based on a user’s Web3 NFTs. Notable examples include [‘members only’ communities](https://rarible.com/blog/9-membership-nfts/) of NFT collectors. This exclusivity extends to video games like [Alien Worlds](https://alienworlds.io/), the [largest web3 game](https://www.statista.com/statistics/1266486/blockchain-games-user-number/) at the end of 2022. NFTs are central to the game and unlock certain content, or game locations are only accessible with specific NFTs. [TravelX](https://travelx.io/) is working on another use case around airline tickets.

Token gating is interesting because of the openness of the attestation. Instead of IAM data being stored on a proprietary server, it’s on a public blockchain for anyone to use and see. We’re just witnessing the first experiments in how that data is used. 

## EVM Compatible, Open Source Coming Soon

The current integration works on all [Ethereum virtual machine (EVM) compatible](https://gocrypto.com/en/what-are-evm-compatible-blockchains/) blockchains. This means you’ll have access to NFTs available on some of the largest NFT marketplaces like [OpenSea](https://opensea.io/). You’ll be able to pull from [Ethereum](https://ethereum.org/en/), [Polygon](https://polygon.technology/), [Avalanche](https://www.avax.network/), [Binance Smart Chain](https://www.bnbchain.org/en), and others. EVM blockchains are the oldest programmable blockchains, and the ecosystem is well supported.

The Auth0 Lab team is working on open-source the code so it can be modified and moved to other blockchain platforms. That process takes some time, so keep an eye out by following us on [Twitter](https://twitter.com/Auth0Lab) or heading to our [GitHub organization](https://github.com/auth0-lab) and give it a follow.

## Unlocking NFTs for Your Application

### How it Works

The Auth0 Lab [fetch-nfts integration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts) works by relying on a few other pieces of infrastructure.

1. It utilizes the [Sign in with Ethereum integration](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/) that SpruceID released in the Auth0 Marketplace in 2022. This allows the integration to grab a public blockchain address for the user, which is critical to querying an NFT smart contract to know if they own an NFT. If a user logs in with a method other than Sign in with Ethereum, NFTs won’t be fetched.
2. During [setup and configuration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts?tab=install), specify a list of NFT contracts that you’d like the [Auth0 Actions](https://auth0.com/actions) code to query. You’ll also need to specify an API key for [The Graph](https://thegraph.com/en/), a service that queries blockchain data.
3. With a public key in hand, and a list of NFT contracts to search, the Actions code calls out to The Graph’s APIs to query the necessary NFT contracts. It returns a list of caip-22 asset references that your Action adds to the [ID token](https://auth0.com/docs/secure/tokens/id-tokens) as claims.
4. From there, you can utilize the data in your application to make any decision, like token gating access, that you feel necessary!

### Installation

Check out our [installation](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts?tab=install) guide to get started!

## What’s Next?

The Auth0 Lab team is actively exploring the best ways to enable developers to build applications that rely on Web3 identity constructs and help bridge the Web2 and Web3 worlds. You can follow our progress on [Twitter](https://twitter.com/auth0lab). If you’re interested in speaking with the team, join our [Discord](https://discord.gg/xkbkz9rZcD) and start a thread.

The [Auth0 Marketplace](https://marketplace.auth0.com/) is looking for Web3 partners to build new extensions onto Auth0. Visit [https://auth0.com/integrate](https://auth0.com/integrate) to learn more.

Web3 NFTs for Identity and Access Control, Now Available on Marketplace

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

Checking user permissions allows you to have more control over access to your ASP.NET Web API.

Protecting a Web API from unauthorized users is the first step to get control over who can access it. However, simply excluding anonymous users may be insufficient in some situations. You may need to control over who can do what on your application. This article will show you how to define and check permissions for users accessing your ASP.NET Web API secured with Auth0.

## The Need for Permissions

A previous article introduced [how to enable authorization for ASP.NET Web APIs](https://auth0.com/blog/aspnet-web-api-authorization/). The sample application accompanying that article is an ASP.NET Web API that implements the CRUD (*Create*, *Retrieve*, *Update*, *Delete*) operations over a glossary of terms. That article explains how to protect the Web API by using Auth0 so that only authorized users can create, modify, and delete glossary items. Everyone can still get the list of terms or a single glossary item.

That worked pretty well! However, you may need more granular control over the users who can do specific operations. For example, you may want to give some users the ability to add a new glossary term or modify an existing one, but you don't want them to delete items. Only specific users should be able also to delete items. To achieve this control level, you must deal with permissions.

In the security context, a **permission** is a property of a resource that indicates the operation a user can do on it, like, for example, read, write, print, send, etc. In the case of your sample application, you have the glossary and term resources. Regarding the former, you can get the list of terms and add new items. Regarding the latter, you can read, update, or delete it.

<details>
  <summary>Permissions vs. privileges</summary>
Usually, permissions and privileges are used interchangeably, but technically they have precise and different meanings in the context of computer security.


A **permission** is an action that can be performed on a resource. It is somehow bounded to the resource, and you can consider it as a resource property.

A **privilege** is a permission assigned to a user or an application. When you assign the writing permission to a user, you are granting them a privilege.
</details>

## Setting up the Web API Application

The goal of this article is to show you how to implement permission-based authorization in this sample application. 

> Make sure you have [the latest .NET SDK](https://dotnet.microsoft.com/download/dotnet/current) already installed on your machine to run the sample ASP.NET application.

So, let's start by downloading the source code with the following command:

```bash
git clone --branch add-authorization --single-branch https://github.com/auth0-blog/glossary-web-api-aspnet.git
```

Once you download the application, register it with Auth0 in order to enable support for the authorization service. If you haven't an Auth0 account, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a>. Follow the [instructions in this article to register the application with Auth0](https://auth0.com/blog/aspnet-web-api-authorization/#Registering-the-Web-API-with-Auth0).

After you completed the registration, move to the `glossary-web-api-aspnet` folder and open the `appsettings.json` configuration file. Its content looks as follows:

```json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "YOUR_AUTH0_DOMAIN",
    "Audience": "YOUR_UNIQUE_IDENTIFIER"
  }
}
```

Replace the `YOUR_AUTH0_DOMAIN` placeholder with your Auth0 domain and the `YOUR_UNIQUE_IDENTIFIER` placeholder with the value you provided as a unique identifier of your API (`https://glossary.com`, if you kept the value suggested in [the mentioned article](https://auth0.com/blog/aspnet-web-api-authorization/#Registering-the-Web-API-with-Auth0)).

> Note: Your Auth0 domain is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

Now, launch the ASP.NET Web API application by typing `dotnet run` in a terminal window. By pointing your browser to `https://localhost:5001/swagger`, you should see the [Swagger UI](https://swagger.io/tools/swagger-ui/) shown below to test the API interactively:

![Protected Web APIs in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/1rNBChKdbCr9fKdpbbYcKR/014f6ace0411febc726959cd88ed8e6a/protected-swagger-ui-webapi.png)

To call the `POST`, `PUT`, and `DELETE` actions, [you need an access token, as explained in this section](https://auth0.com/blog/aspnet-web-api-authorization/#Testing-the-Secure-Web-API).

Now you are ready to set up permissions on your Web API.

## Defining Permissions for an API

The first step is to define the permissions for your application. These permissions can vary depending on the needs of your application. In the glossary Web API application, we are going to define the permissions identified by the following strings:

- `create:term`. This permission allows you to add a new term to the glossary.
- `update:term`. With this permission, you can update an existing term.
- `delete:term`. This permission allows you to delete a term from the glossary.

To associate these permissions with your API, go to the [API section](https://manage.auth0.com/#/apis) of your Auth0 Dashboard and select the API you defined for the glossary application. Then select the *Permissions* tab. Here you can add the permissions with their descriptions as defined above. At the end of this process, that page will look like the following:

![Defining permissions in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/52FOUrB7EcV17WYLSjdbDS/19d1360d9def0ea77cc550ba664a7748/defining-permissions-auth0-dashboard.png.png)

This configuration informs Auth0 that the glossary Web API supports only these permissions.

Next, move to the *Settings* tab and scroll down to the *RBAC Settings* section. Here, click both the *Enable RBAC* and the *Add Permissions in the Access Token* toggle buttons, as in the following picture, and don't forget to click the *Save* button at the end:

![](https://images.ctfassets.net/23aumh6u8s0i/49AQnZIW5pP4wBIHA4sV9i/2c476e2508ff68fde80061b6973016ca/enabling-rbac.png)

These settings will enforce the evaluation  of roles and permissions assignments during the user login.

> Although we will not use roles in this article, you still need to enable RBAC (Role-Based Access Control) support.



<details>
  <summary>Permissions vs. scopes</summary>
When defining the API permissions in the Auth0 Dashboard, you find the term *scope* next to the term *permission*. You may think that they are synonymous, but they actually aren't. Both describe the actions that can be performed on a resource, but they are used in different authorization scenarios.

**Permissions** are used in a [first-party authorization scenario](https://auth0.com/docs/applications/first-party-and-third-party-applications#first-party-applications), i.e., when the same organization or person controls both the client and the server applications.

**Scopes** are used in a [third-party authorization scenario](https://auth0.com/docs/applications/first-party-and-third-party-applications#third-party-applications), i.e., when different organizations control the client and the server applications.

In the latter scenario, the client application asks for one or more permissions to operate on a specific resource on behalf of the user. This requested permission is a **scope**. Usually, scopes limit what an app can do on behalf of the user, and the user may grant them to the application or not.

Scopes have been [introduced by OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) in the context of delegated authorization.
</details>

## Checking Permissions in an API

As the next step, you need to check that the user calling your API has the proper permissions. You can accomplish this task by defining one or more authorization policies and applying them to the controller or the methods that implement your ASP.NET Web API.

An **authorization policy** is a set of requirements that users or applications must meet in order to be allowed to perform an action on a resource. Let's see how you can define and apply an authorization policy in practice.

### Registering an authorization policy

To define an authorization policy for the glossary Web API, open the `Startup.cs` file in the root folder of the project and append the following code to the body of the `ConfigureServices()` method:

```csharp
// Startup.cs

// ...existing code...

namespace Glossary
{
  public class Startup
  {
    // ...existing code...
    
    public void ConfigureServices(IServiceCollection services)
    {
      // ...existing code...
      
      //👇 new code
      services.AddAuthorization(options =>
      {
        options.AddPolicy("WriteAccess", policy => 
                          policy.RequireClaim("permissions", "create:term", "update:term"));
        options.AddPolicy("DeleteAccess", policy => 
                          policy.RequireClaim("permissions", "delete:term"));
      });
      //👆 new code
    }
    
    // ...existing code...
  }
}

```

You invoked the `AddAuthorization()` method to configure the ASP.NET authorization service. To this purpose, you defined two authorization policies via the `AddPolicy()` method of the `options` parameter. Each policy has a name and a lambda expression. For example, the `WriteAccess` authorization policy is defined by requiring the `permissions` [claim](https://auth0.com/docs/tokens/json-web-tokens/json-web-token-claims) in the access token whose value can be `create:term` or `update:term`. Similarly, for the `DeleteAccess` policy.

### Authorization policy approaches

You defined two authorization policies based on the permissions you defined for the API in the Auth0 Dashboard. Both policies are based on requiring the existence of claims with specific values. This is the simplest way to define an authorization policy in ASP.NET. It is usually referred to as [claim-based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims).

If you have more complex criteria for defining your authorization policies, you need to use the [policy-based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies) approach. For example, if you want to be sure that the issuer of the `permissions` claim is your [Auth0 tenant](https://auth0.com/docs/get-started/create-tenants), you can define your `WriteAccess` authorization policy as follows:

```csharp
options.AddPolicy("WriteAccess", policy => 
                    policy.RequireAssertion(context =>
                       context.User.HasClaim(claim =>
                         (claim.Type == "permissions" &&
                          (claim.Value == "create:term" ||
                           claim.Value == "update:term") &&
                          claim.Issuer == $"https://{Configuration["Auth0:Domain"]}/"
                         )
                       )
                    )
                  );
```

In this case, you used the `RequireAssertion()` method to build a boolean expression that evaluates your specific criteria. In particular, this criteria checks that the `Issuer` property of the claim matches the URL of your Auth0 tenant.

> Note that claim-based authorization is just a specialized case of policy-based authorization.

If you have more specific needs, you can even [customize the built-in ASP.NET authorization middleware](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/customizingauthorizationmiddlewareresponse).

### Applying an authorization policy

Once you define and register your authorization policies, you can apply them in your Web API. Applying an authorization policy is just a matter of passing parameters to the `Authorize` attribute. So, open the `GlossaryController.cs` file under the `Controllers` folder and apply the changes outlined in the following:

```csharp
// Controllers/GlossaryController.cs

// ...existing code...

namespace Glossary.Controllers
{
  [ApiController]
  [Route("api/[controller]")]
  public class GlossaryController : ControllerBase
  {
    // ...existing code...

    [HttpPost]
    [Authorize(Policy = "WriteAccess")]    //👈 changed code
    public ActionResult Post(GlossaryItem glossaryItem)
    {
      // ...existing code...
    }

    [HttpPut]
    [Authorize(Policy = "WriteAccess")]    //👈 changed code
    public ActionResult Put(GlossaryItem glossaryItem)
    {
      // ...existing code...
    }

    [HttpDelete]
    [Route("{term}")]
    [Authorize(Policy = "DeleteAccess")]    //👈 changed code
    public ActionResult Delete(string term)
    {
      // ...existing code...
    }
  }
}
```

This way, you are requesting the ASP.NET authorization middleware to evaluate a specific policy to authorize the execution of the related controller's method.

Your Web API is ready to run and check permissions!

## Testing Permissions

To test the new glossary Web API, you are going to simulate users accessing the endpoints with different permissions. For this simulation, you will interact with the API through the Swagger UI by providing an access token. So, launch the Web API by typing `dotnet run` in a terminal window and point your browser to [https://localhost:5001/swagger](https://localhost:5001/swagger).

### Testing access without permissions

Let's try to access a protected endpoint with an access token not bound to any permissions. Go to the [API section](https://manage.auth0.com/#/apis) of your Auth0 Dashboard, select the API related to the glossary app, and select the *Test* tab. Here you can get a token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Copy access token](https://images.ctfassets.net/23aumh6u8s0i/1FENUfKNw5FrmexhvdWwv5/bb1c283a019dc0fd7322e357efd1bdb2/copy-token.png)

Now, head back to your browser and click the *Authorize* button. A window dialog opens, as shown in the following picture:

![Bearer token in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/18f9kh3tBXiOMbxjSA7j1k/c0ab1d1475b75ef51a50a1009ea3c5c1/access-token-swagger-ui.png)

Paste the token you copied from the Auth0 Dashboard into the text box and click *Authorize*.

> To learn a bit more about the Swagger UI, check out [this article about ASP.NET Web API authorization](https://auth0.com/blog/aspnet-web-api-authorization/).

Now, try to add a new glossary term through the `POST` action. You should get a negative response from the server similar to this one:

![Forbidden action on an endpoint](https://images.ctfassets.net/23aumh6u8s0i/2jJfEWsECwVKy9qwcy7Nyk/182e158601d78774ee3fd633028badea/forbidden-action-on-endpoint.png)

Notice that, this time, you didn't receive the `401 Unauthorized` HTTP status code. You received the `403 Forbidden` status code. This denotes that you are providing an access token, so you are authorized to access the application, but you don't have the required permissions to perform this specific action.

You can verify your current permissions by visiting [jwt.io](https://jwt.io/) and pasting your access token there. This tool allows you to decode your access token. You will discover that the `permissions` claim shown in the payload section is an empty array, as in the following picture:

![Empty permissions claim in JWT](https://images.ctfassets.net/23aumh6u8s0i/5bMNrF4vS9iYs3hQuxCMe2/d8bffd83f61373f5b9a6e2b0d69691b6/empty-permissions-claim-in-jwt.png)

### Testing access with writing permissions

Let's create an access token with the required permissions for adding a new term.

Back in your API configuration page on the Auth0 Dashboard, select the *Machine to Machine Applications* tab. You'll get a list of applications, some of them with the *(Test Application)* label in the name. These applications are automatically created by Auth0 when you create an API there. They are meant as test clients from your API. One of them should have the *Authorized* switch on. Click the dropdown next to it and check the `create:term` and `update:term` permissions in the section that will be shown:

![Writing permissions assignment](https://images.ctfassets.net/23aumh6u8s0i/1noHOvxBZaRERXAJ9SpPt2/849b32e5f54524cc3e6f3e58eb1f3578/assign-writing-permissions.png)

Then, click the *Update* button, move again to the *Test* tab, and copy the new token that has been generated for you. Now, in the Swagger UI of your Web API, click the *Authorize* button again. This time the following window should appear:

![Changing the access token](https://images.ctfassets.net/23aumh6u8s0i/1WKMrki5ZtwLPvBKmoQ1Gv/b276253e73ed5848f804ac69a37718d3/changing-access-token.png)

Click the *Logout* button and paste the new access token in the text box that appears.

At this point, try again to add a new term to the glossary through the `POST` action. Now you should get a successful response from the server.

If you decode your new access token in [jwt.io](https://jwt.io/), you should see that the `permissions` claim now contains the two permissions you assigned:

![Writing permissions in JWT](https://images.ctfassets.net/23aumh6u8s0i/WVVEcOwuIeuB73aYKu0Q0/e8a722919757b259befd52ddc09dfdf5/writing-permissions-in-jwt.png)

If you attempt to delete the newly created term with the same access token, you get the `403 Forbidden` status code as before. In fact, your access token doesn't contain the deleting permission.

### Testing access with deleting permissions

To be authorized to delete a glossary term, you need to grant the deleting permission to the test application. So, go back to the *Machine to Machine Application* tab of your API configuration on the Auth0 Dashboard and open the permissions section of the test application again. Check also the `delete:term` permission and click the *Update* button. Now, in the *Test* tab, copy the new access token and head back to your browser.

In the Swagger UI of your Web API, replace your current access token with the new one by using the *Authorize* button. Then, delete the glossary term you added earlier by using the `DELETE` action. This time your attempt should be successful!

## Recap

In summary, you learned that permissions give you more granular control over access to your Web API. You discovered how to define permissions associated with your API in Auth0 and how to define and register authorization policies in your ASP.NET application. You saw that checking permissions in your API controller is a matter of adding a parameter to the `Authorize` attribute. You used your test client application on the Auth0 Dashboard to generate access tokens with the required permissions. Finally, you used the Swagger UI to test your Web API with access tokens having different permissions.

You can download the final code of the sample application from [this GitHub repository](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/add-permission).


Permission-Based Security for ASP.NET Web APIs

500x500

I'm a software engineer, but I prefer to call myself Technology Bishop. Spreading knowledge through writing is my mission.

Antonello Zanini

Learn how to implement custom error handling logic in Spring Boot. You will see two approaches based on the @ControllerAdvice annotation. Similarly, you will learn how to deal with authentication and access denied errors in Spring Security.

Get Started with Custom Error Handling in Spring Boot (Java)

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

Permissions-based access controls ease administrator management



**BELLEVUE, Wash. — November 25, 2019 —** Auth0, the identity platform for application builders, today announced its integration with Session Tags, a new IAM feature from AWS. This integration provides AWS users with access to the right information based on their user attributes, and reduces the number of AWS roles and permissions policies the administrator has to manage and update when employees’ responsibilities change. 

Customers frequently manage their workforce identities using an identity provider (IdP), federating from it into AWS using industry standards such as SAML and OIDC. Now, with session tags, when users federate into AWS, Auth0 can be configured to send attributes — for example  an environment tag, project tag, team tag, and cost center tag — which are then used to determine the correct IAM policies for controlling access to AWS resources. 

Customers can rely on the attributes from their corporate directory and ensure each employee receives defined permissions based on those attributes during an AWS session, simplifying fine-grained access control. Customers are able to scale more quickly without the administrator burden, and have a verifiable audit trail for permissions-based changes. 

“A lot of customers use attributed-based access control now, but are not able to make use of their existing IdPs to do so,” said Bill Lapcevic, VP of Business Development at Auth0. “Thanks to our integration with Session Tags, AWS IAM users will benefit from the ability to use existing attributes to automatically apply specified permissions, giving power back to the IdP as the source of truth for access control.” 

Please visit our [technical documentation](https://auth0.com/docs/integrations/aws) on Session Tags for more details on how to implement this feature.

<include src="asides/AboutAuth0" />


"access control"