deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Staff Developer Advocate at Okta. He is also an international speaker and a published author.

Staff Developer Advocate

Deepu K Sasidharan

Learn how to use Okta FGA to secure your LlamaIndex RAG agent on Node.js.

Generative Artificial Intelligence (GenAI) has massively changed the software landscape and AI agents are all the rage now. AI agents can also be used for complex Retrieval-Augmented Generation (RAG) systems where additional context can be provided to the Large Language Model (LLM) by retrieving updated or domain-specific data from a database or a search engine. This technique can reduce hallucinations and improve accuracy of the LLM. AI agents can also use RAG as a tool to perform complex workflows.

[Sensitive Information Disclosure](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) is a common issue that plagues RAG-based systems. We don't want the LLM to accidentally access or expose sensitive data from a database. Traditional Role-Based Access Control (RBAC) systems are not enough to secure RAG applications and agents. This is where [Fine-Grained Authorization (FGA)](https://fga.dev/) shines as a solution.

If you would like to learn the basics of using FGA for RAG, check out this blog post on [RAG and Access Control: Where Do You Start?](https://auth0.com/blog/rag-and-access-control-where-do-you-start/).

<include
  src="LinkCard"
  title="RAG and Access Control: Where Do You Start?"
  link="https://auth0.com/blog/rag-and-access-control-where-do-you-start/"
  description="Learn how to get started with Okta FGA for a RAG application."
  img="https://images.ctfassets.net/23aumh6u8s0i/79NCborGcFIrAMeaV7G8oi/f9c588c2d05f0828d447e72e1fe825cc/Latam01.jpg"
/>

In this tutorial, we will build a simple RAG agent using the [LlamaIndex.TS](https://ts.llamaindex.ai/), which is the JavaScript version of the popular [LlamaIndex](https://www.llamaindex.ai/) framework, and secure it using Okta FGA.

## Prerequisites

> **This tutorial was created with the following tools and services**:
>
> - [NodeJS v20](https://nodejs.org/en/download)
> - An Okta FGA account. [Create one](https://dashboard.fga.dev).
> - An OpenAI account and API key. [Create one](https://platform.openai.com).

## What Does LlamaIndex Do?

[LlamaIndex](https://www.llamaindex.ai/) is a flexible framework for building AI agents and RAG applications. It provides Python and JavaScript SDKs to interact with a variety of LLMs and databases. LlamaIndex can be used to build AI agents and workflows that can interact with the user, retrieve data from a database, and generate responses using an LLM. It also provides tools like [LlamaParse](https://www.llamaindex.ai/llamaparse) to transform unstructured data into LLM-optimized formats and LlamaCloud to store and retrieve LLM-ready data from the cloud.

## Set up a LlamaIndex RAG Application

To get started, clone the [**auth0-ai-samples**](https://a0.to/auth0-ai-samples) repository from GitHub:

```bash
git clone https://github.com/auth0-samples/auth0-ai-samples.git
cd auth0-ai-samples/authorization-for-rag/llamaindex-agentic-js
# install dependencies
npm install
```

The application is written in TypeScript for the Node.js platform and is structured as follows:

- `index.ts`: The main entry point of the application that defines the RAG pipeline.
- `assets/docs/*.md`: Sample markdown documents that will be used as context for the LLM. We have public and private documents for demonstration purposes.
- `scripts/fga-init.ts`: Utility to initialize the Okta FGA authorization model.

Let us look at the important bits and pieces before we run the application.

### RAG pipeline

The RAG pipeline is defined in `index.ts`. It uses LlamaIndex Agents to interact with the underlying LLM and retrieve data from the database. The pipeline is defined as follows:

```typescript
/** index.ts **/
const user = 'user1';
// 1. Read and load documents from the assets folder
const documents = await new SimpleDirectoryReader().loadData('./assets/docs');
// 2. Create an in-memory vector store from the documents using the default OpenAI embeddings
const vectorStoreIndex = await VectorStoreIndex.fromDocuments(documents);
// 3. Create a retriever that uses FGA to gate fetching documents on permissions.
const retriever = FGARetriever.create({
  // Set the similarityTopK to retrieve more documents as SimpleDirectoryReader creates chunks
  retriever: vectorStoreIndex.asRetriever({ similarityTopK: 30 }),
  // FGA tuple to query for the user's permissions
  buildQuery: (document) => ({
    user: `user:${user}`,
    object: `doc:${document.metadata.file_name.split('.')[0]}`,
    relation: 'viewer',
  }),
});
// 4. Create a query engine and convert it into a tool
const queryEngine = vectorStoreIndex.asQueryEngine({ retriever });
const tools = [
  new QueryEngineTool({
    queryEngine,
    metadata: {
      name: 'zeko-internal-tool',
      description: `This tool can answer detailed questions about ZEKO.`,
    },
  }),
];

// 5. Create an agent using the tools array and OpenAI GPT-4 LLM
const agent = new OpenAIAgent({ tools });

// 6. Query the agent
let response = await agent.chat({ message: 'Show me forecast for ZEKO?' });
```

Here is a visual representation of the RAG architecture

![LlamaIndex RAG architecture](https://images.ctfassets.net/23aumh6u8s0i/lGssMbzaSU4J0zXG4bFcC/21f2abbda55a13640350d637609469f7/llamaindex-rag.jpg)

### FGA retriever

The `FGARetriever` class filters documents based on the authorization model defined in Okta FGA and will be available as part of the [**auth0-ai-js**](https://github.com/auth0-lab/auth0-ai-js) SDK. This retriever is a post-search filter ideal for scenarios where you already have documents in a vector store and want to filter the vector store results based on the user's permissions. Assuming the vector store already narrows down the documents to a few, the FGA retriever will further narrow down the documents to only the ones to which the user has access.

The alpha version of the retriever can be installed using the following command:

```bash
npm install "https://github.com/auth0-lab/auth0-ai-js.git#alpha-2" --save
```

The build query function is used to construct the query to the FGA store. The query is constructed using the user, object, and relation. The user is the user ID, the object is the document ID or the document name, and the relation is the permission that the user must have on the document.

```typescript
buildQuery: (document) => ({
  user: `user:${user}`,
  object: `doc:${document.metadata.file_name.split(".")[0]}`,
  relation: "viewer",
}),
```

### Retrieval Agent

1. The `queryEngine` is created from the vector store index and configured to use our custom FGA retriever. The query engine handles searching through documents and retrieving relevant information based on user queries.

2. The `tools` array contains a `QueryEngineTool` that wraps our query engine. The tool provides a structured interface for the agent to access the query engine's capabilities.

3. The `agent` is created using OpenAI's GPT-4 model and the tools array. The agent acts as an intelligent interface between the user and the tools - it understands natural language queries, determines when to use the query engine tool, and formulates responses based on the retrieved information.

```typescript
/** index.ts **/
const queryEngine = vectorStoreIndex.asQueryEngine({ retriever });
const tools = [
  new QueryEngineTool({
    queryEngine,
    metadata: {
      name: 'zeko-internal-tool',
      description: `This tool can answer detailed questions about ZEKO.`,
    },
  }),
];

// 5. Create an agent using the tools array and OpenAI GPT-4 LLM
const agent = new OpenAIAgent({ tools });
```

## Set up an FGA Store

In the [Okta FGA dashboard](https://dashboard.fga.dev/), navigate to **Settings**, and in the **Authorized Clients** section, click **+ Create Client**. Give your client a name, mark all three client permissions, and then click **Create**.

![Create FGA client](https://images.ctfassets.net/23aumh6u8s0i/2KQc8ACR0MDTqftUgUSXpX/5b779bcece07a69ac775de0fc760c208/Uploaded_from_RAG_and_Access_Control__Where_Do_You_Start)

Once your client is created, you’ll see a modal containing Store ID, Client ID, and Client Secret.

Add `.env` file with the following content to the root of the project. Click **Continue** to see the `FGA_API_URL` and `FGA_API_AUDIENCE`.

```
# OpenAI
OPENAI_API_KEY=<your-openai-api-key>

# Okta FGA
FGA_STORE_ID=<your-fga-store-id>
FGA_CLIENT_ID=<your-fga-store-client-id>
FGA_CLIENT_SECRET=<your-fga-store-client-secret>
# Required only for non-US regions
FGA_API_URL=https://api.xxx.fga.dev
FGA_API_AUDIENCE=https://api.xxx.fga.dev/
```

[Check the instructions here to find your OpenAI API key](https://help.openai.com/en/articles/4936850-where-do-i-find-my-openai-api-key).

Next, navigate to **Model Explorer**. You’ll need to update the model information with this:

```text
model
  schema 1.1

type user

type doc
  relations
    define owner: [user]
    define viewer: [user, user:*]
```

Remember to click **Save**.

> Check out [this documentation to learn more about creating an authorization model in FGA](https://docs.fga.dev/modeling).

Now, to have access to the public information, you’ll need to add a tuple on FGA. Navigate to the **Tuple Management** section and click **+ Add Tuple**, fill in the following information:

- **User** : `user:*`
- **Object** : select doc and add `public-doc` in the ID field
- **Relation** : `viewer`

A tuple signifies a user’s relation to a given object. For example, the above tuple implies that all users can view the `public-doc` object.

> Alternatively, you can use the `scripts/fga-init.ts` script to initialize the FGA store with the model and tuple.
> Run the `npm run fga:init` command after setting up the `.env` file.

## Test the Application

Now that you have set up the application and the FGA store, you can run the application using the following command:

```bash
npm start
```

The application will start with the query, `Show me forecast for ZEKO?` Since this information is in a private document, and we haven't defined a tuple with access to this document, the application will not be able to retrieve it. The FGA retriever will filter out the private document from the vector store results and, hence, print a similar output.

```text
The provided context does not include specific forecasts or projections for Zeko Advanced Systems Inc. ...
```

If you change the query to something that is available in the public document, the application will be able to retrieve the information.

Now, to have access to the private information, you’ll need to update your tuple list. Go back to the Okta FGA dashboard in the **Tuple Management** section and click **+ Add Tuple**, fill in the following information:

- **User** : `user:user1`
- **Object** : select doc and add `private-doc` in the ID field
- **Relation** : `viewer`

Now click **Add Tuple** and then run the script again:

```bash
npm start
```

This time, you should see a response containing the forecast information since we added a tuple that defines the `viewer` relation for `user1` to the `private-doc` object.

Congratulations! You have run a simple RAG application using LlamaIndex and secured it using Okta FGA.

## Learn More about Auth for GenAI, Okta FGA and GenAI

In this post, you learned how to secure a LlamaIndex-based RAG application using Auth0's [Auth for GenAI](https://a0.to/ai-content) and [Okta FGA](https://fga.dev/). Okta FGA is built on top of OpenFGA, which is open-source. We invite you to check out the [OpenFGA code on GitHub](https://a0.to/fga_repo).

Before you go, we have some great news to share: we are working on more content and sample apps in collaboration with amazing GenAI frameworks like [LlamaIndex](https://www.llamaindex.ai/), [LangChain](https://www.langchain.com/), [CrewAI](https://www.crewai.com/), [Vercel AI SDK](https://sdk.vercel.ai/), and [GenKit](https://firebase.google.com/docs/genkit). [Auth for GenAI](https://auth0.com/blog/auth-for-genai/) is our upcoming product to help you protect your user's information in GenAI-powered applications. Make sure to join the [Auth0 Lab Discord server](http://a0.to/auth0-lab-discord) to hear more and ask questions.

Build a Secure RAG Agent Using LlamaIndex and Okta FGA on Node.js

Learn how to use Okta FGA to secure your LangChain RAG agent on Node.js

Like it or not, Generative Artificial Intelligence (GenAI) has massively changed the software landscape. Retrieval-Augmented Generation (RAG) is a cornerstone of GenAI-powered applications. It is an architecture that improves the accuracy of Large Language Models (LLMs) by providing more context to the model. This is done by retrieving updated or domain-specific data from a database or a search engine. This is a powerful technique that can be used to improve the accuracy of LLMs in a variety of applications.

Security is even more paramount when it comes to RAG-based systems, as we don't want the LLM to accidentally access or expose sensitive data. Traditional Role-Based Access Control (RBAC) systems are not enough to secure RAG applications. This is where [Fine-Grained Authorization (FGA)](https://fga.dev/) comes to the rescue.

If you would like to learn the basics of using FGA for RAG, check out this blog post on [RAG and Access Control: Where Do You Start?](https://auth0.com/blog/rag-and-access-control-where-do-you-start/)

<include
  src="LinkCard"
  title="RAG and Access Control: Where Do You Start?"
  link="https://auth0.com/blog/rag-and-access-control-where-do-you-start/"
  description="Learn how to get started with Okta FGA for a RAG application."
  img="https://images.ctfassets.net/23aumh6u8s0i/79NCborGcFIrAMeaV7G8oi/f9c588c2d05f0828d447e72e1fe825cc/Latam01.jpg"
/>

In this tutorial, we will build a simple RAG agent using the [LangChain](https://www.langchain.com/) framework and secure it using Okta FGA.

<AmpContent>
<amp-youtube
    data-videoid="u81b6nsDoPA"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

<NonAmpContent>
<div
  className='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/u81b6nsDoPA'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>


## Prerequisites

> **This tutorial was created with the following tools and services**:
>
> - [NodeJS v20](https://nodejs.org/en/download)
> - An Okta FGA account. [Create one](https://dashboard.fga.dev).
> - An OpenAI account and API key. [Create one](https://platform.openai.com).

## Why LangChain?

[LangChain](https://www.langchain.com/) is one of the leading frameworks for building context-aware reasoning applications, including RAG applications. It is open-source and provides a simple API to interact with the underlying LLMs. It supports a variety of LLMs, including OpenAI's GPT models, Google VertexAI, Anthropic, and more. It also provides a simple way to retrieve data from a database or a search engine to provide more context to the LLM. For this tutorial, we will use [LangGraph](https://www.langchain.com/langgraph) from LangChain to build an agentic RAG application. LangGraph is a powerful tool that allows you to build agents that can handle complex tasks, including RAG applications. It provides advanced features like workflows, persisted context, and streaming support.

## Set up a LangGraph RAG application

To get started, clone the [**auth0-ai-samples**](https://a0.to/auth0-ai-samples) repository from GitHub:

```bash
git clone https://github.com/auth0-samples/auth0-ai-samples.git
cd auth0-ai-samples/authorization-for-rag/langgraph-agentic-js
# install dependencies
npm install
```

The application is written in TypeScript for the Node.js platform and is structured as follows:

- `index.ts`: The main entry point of the application that defines the RAG pipeline.
- `assets/docs/*.md`: Sample markdown documents that will be used as context for the LLM. We have public and private documents for demonstration purposes.
- `helpers/read-documents.ts`: Utility to load markdown files as documents.
- `helpers/langchain.ts`: Defines the LangGraph retrieval agent.
- `scripts/fga-init.ts`: Utility to initialize the Okta FGA authorization model.

Let us look at the important bits and pieces before we run the application.

### RAG pipeline

The RAG pipeline is defined in `index.ts`. It uses the LangGraph framework to interact with the underlying LLM and retrieve data from the database. The pipeline is defined as follows:

```js
/** index.ts **/
const user = 'user1';
// 1. Read and load documents from the assets folder
const documents = await readDocuments();
// 2. Create an in-memory vector store from the documents for OpenAI models.
const vectorStore = await MemoryVectorStore.fromDocuments(
  documents,
  new OpenAIEmbeddings({ model: 'text-embedding-3-small' }),
);
// 3. Create a retriever that uses FGA to gate fetching documents on permissions.
const retriever = FGARetriever.create({
  retriever: vectorStore.asRetriever(),
  // FGA tuple to query for the user's permissions
  buildQuery: (doc) => ({
    user: `user:${user}`,
    object: `doc:${doc.metadata.id}`,
    relation: 'viewer',
  }),
});
// 4. Convert the retriever into a tool for an agent.
const fgaTool = retriever.asJoinedStringTool();
// 5. The agent will call the tool, rephrasing the original question and
// populating the "query" argument, until it can answer the user's question.
const retrievalAgent = RetrievalAgent.create([fgaTool]);
// 6. Query the retrieval agent with a prompt
const answer = await retrievalAgent.query('Show me forecast for ZEKO?');
```

Here is a visual representation of the RAG architecture:

![LangChain RAG architecture](https://images.ctfassets.net/23aumh6u8s0i/707VuhSJ2FqDBTrQNP6rTl/0fcd90a881441369e1466b109c02686c/langgraph-rag.jpg)

### FGA retriever

The `FGARetriever` class filters documents based on the authorization model defined in Okta FGA and will be available as part of the [**auth0-ai-js**](https://github.com/auth0-lab/auth0-ai-js) SDK. This retriever is ideal for scenarios where you already have documents in a vector store and want to filter the vector store results based on the user's permissions. Assuming the vector store already narrows down the documents to a few, the FGA retriever will further narrow down the documents to only the ones that the user has access to. 

The alpha version of the retriever can be installed using the following command:

```bash
npm install "https://github.com/auth0-lab/auth0-ai-js.git#alpha-1" --save
```

The build query function is used to construct the query to the FGA store. The query is constructed using the user, object, and relation. The user is the user ID, the object is the document ID, and the relation is the permission that the user has on the document.

```typescript
buildQuery: (doc) => ({
  user: `user:${user}`,
  object: `doc:${doc.metadata.id}`,
  relation: 'viewer',
}),
```

### Retrieval Agent

The `RetrievalAgent` class configures a LangGraph retrieval agent that uses the FGA retriever tool and an OpenAI model to answer the user's question. The agent will call the tool to get context documents in this case.

```typescript
/** helpers/langchain.ts **/
static create(tools: StructuredToolInterface[]) {
  // Create a retrieval agent that has access to the retrieval tool.
  const retrievalAgent = createReactAgent({
    llm: new ChatOpenAI({ temperature: 0, model: 'gpt-4o-mini' }),
    tools,
    stateModifier: [
      "Answer the user's question only based on context retrieved from provided tools.",
      'Only use the information provided by the tools.',
      'If you need more information, ask for it.',
    ].join(' '),
  });
  return new RetrievalAgent(retrievalAgent);
}
```

## Set up an FGA store

In the [Okta FGA dashboard](https://dashboard.fga.dev/), navigate to **Settings**, and in the **Authorized Clients** section, click **+ Create Client**. Give your client a name, mark all three client permissions, and then click **Create**.


![Create FGA client](https://images.ctfassets.net/23aumh6u8s0i/2KQc8ACR0MDTqftUgUSXpX/5b779bcece07a69ac775de0fc760c208/Uploaded_from_RAG_and_Access_Control__Where_Do_You_Start)


Once your client is created, you’ll see a modal containing Store ID, Client ID, and Client Secret.

Add `.env` file with the following content to the root of the project. Click **Continue** to see the `FGA_API_URL` and `FGA_API_AUDIENCE`.

```
# OpenAI
OPENAI_API_KEY=<your-openai-api-key>

# Okta FGA
FGA_STORE_ID=<your-fga-store-id>
FGA_CLIENT_ID=<your-fga-store-client-id>
FGA_CLIENT_SECRET=<your-fga-store-client-secret>
# Required only for non-US regions
FGA_API_URL=https://api.xxx.fga.dev
FGA_API_AUDIENCE=https://api.xxx.fga.dev/
```

[Check the instructions here to find your OpenAI API key](https://help.openai.com/en/articles/4936850-where-do-i-find-my-openai-api-key).

Next, navigate to **Model Explorer**. You’ll need to update the model information with this:

```text
model
  schema 1.1

type user

type doc
  relations
    define owner: [user]
    define viewer: [user, user:*]
```

Remember to click **Save**.

> Check out [this documentation to learn more about creating an authorization model in FGA](https://docs.fga.dev/modeling).

Now, to have access to the public information, you’ll need to add a tuple on FGA. Navigate to the **Tuple Management** section and click **+ Add Tuple**, fill in the following information:

- **User**: `user:*`
- **Object**: select doc and add `public-doc` in the ID field
- **Relation**: `viewer`

A tuple signifies a user’s relation to a given object. For example, the above tuple implies that all users can view the `public-doc` object.

> Alternatively, you can use the `scripts/fga-init.ts` script to initialize the FGA store with the model and tuple.
> Run the `npm run fga:init` command after setting up the `.env` file.

## Test the application

Now that you have set up the application and the FGA store, you can run the application using the following command:

```bash
npm start
```

The application will start with the query, `Show me forecast for ZEKO?` Since this information is in a private document, and we haven't defined a tuple with access to this document, the application will not be able to retrieve it. The FGA retriever will filter out the private document from the vector store results and, hence, print a similar output.

```text
The provided context does not include specific forecasts or projections for Zeko Advanced Systems Inc. ...
```

If you change the query to something that is available in the public document, the application will be able to retrieve the information.

Now, to have access to the private information, you’ll need to update your tuple list. Go back to the Okta FGA dashboard in the **Tuple Management** section and click **+ Add Tuple**, fill in the following information:

- **User**: `user:user1`
- **Object**: select doc and add `private-doc` in the ID field
- **Relation**: `viewer`

Now click **Add Tuple** and then run the script again:

```bash
npm start
```

This time, you should see a response containing the forecast information since we added a tuple that defines the `viewer` relation for `user1` to the `private-doc` object.

Congratulations! You have run a simple RAG application using LangChain and secured it using Okta FGA.

## Learn more about Auth0 for GenAI, Okta FGA and GenAI

In this post, you learned how to secure a LangChain-based RAG application using Auth0's [Auth for GenAI](https://a0.to/ai-content) and [Okta FGA](https://fga.dev/). Okta FGA is built on top of OpenFGA, which is open-source. We invite you to check out the [OpenFGA code on GitHub](https://a0.to/fga_repo).

Before you go, we have some great news to share: we are working on more content and sample apps in collaboration with amazing GenAI frameworks like [LlamaIndex](https://www.llamaindex.ai/), [LangChain](https://www.langchain.com/), [CrewAI](https://www.crewai.com/), [Vercel AI SDK](https://sdk.vercel.ai/), and [GenKit](https://firebase.google.com/docs/genkit). [Auth for GenAI](https://auth0.com/blog/auth-for-genai/) is our upcoming product to help you protect your user's information in GenAI-powered applications. Make sure to join the [Auth0 Lab Discord server](http://a0.to/auth0-lab-discord) to hear more and ask questions.


Build a Secure LangChain RAG Agent Using Okta FGA and LangGraph on Node.js

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

Juan Cruz Martinez

Learn how to use Okta FGA to secure your LangChain RAG agent in Python.

Retrieval-Augmented Generation (RAG) is a great way to create AI-driven applications that deliver more accurate, context-rich answers. Instead of relying purely on pre-trained knowledge, a RAG system retrieves domain-specific data (like PDFs, knowledge bases, or markdown files) and passes it into a language model. This is *awesome* when your data is public or freely shareable. But what happens if some of that data is *restricted* or *confidential*? That’s where fine-grained authorization comes in!

In this post, we’ll walk through:

1. **Why** authorization is crucial in RAG
2. **What** OpenFGA is, and how it helps you enforce fine-grained permissions
3. **How** to build a secure pipeline that filters out unauthorized documents **before** they reach your language model

## The Challenge of Authorization in RAG Systems

RAG systems retrieve relevant information from large datasets and use that information to enhance the AI model responses. While this functionality is powerful, it raises a significant challenge: **ensuring that each user only accesses the information they are authorized to see**. Authorization must be:

* **Accurate**: Only correct data gets through.
* **Performant**: Works quickly, even with large datasets.
* **Adaptive**: Updates with dynamic organizational changes, role updates, or any changes in the relationship between the information and the users.

A secure RAG system needs to enforce fine-grained access control without sacrificing speed or scalability. Roles might change, projects can be reassigned, and permissions could evolve over time. Handling all this efficiently is key to building a truly secure and robust RAG application.

## Proposed Solution: Secure Retrieval with LangChain, OpenAI, and OpenFGA

The solution employs a workflow that integrates document retrieval, user-specific authorization filtering, and Large Language Model (LLM) response generation.

We’ll build a pipeline that uses:

* **LangChain**: A helpful toolkit for chaining the steps of a RAG pipeline (loading data, embeddings, retrieval, prompting).
* **LLMs** (OpenAI or any other): For both embeddings (similarity search) and text generation.
* **OpenFGA**: A fine-grained authorization service that checks, for each document, if a user has the “can_view” relationship.

### LangChain

LangChain is a library that streamlines building LLM applications by assembling different components—like loading documents, vector stores, and prompt templates. This structure makes it easier to read, maintain, and modify your RAG pipeline.

### LLMs

Although we’ll demonstrate OpenAI’s embeddings and Chat APIs, you can easily replace them with other providers (e.g., Anthropic, LLaMA, or Azure OpenAI). The main tasks here are:

1. **Embedding** documents so you can do similarity searches.
2. **Generating** text from the retrieved documents to answer the user’s query.

### FGA and Okta FGA

**FGA (Fine-Grained Authorization)** is about controlling _who can do what_ with _which resources_, down to an individual level. In a typical role-based system, you might say, “Admins can see everything, and Regular Users can see some subset.” But in a real-world app—especially one that deals with many documents—this might not be flexible enough.

**OpenFGA (and Okta FGA)** addresses this by letting you define authorization _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.

If you would like to learn the basics of using FGA for RAG, check out this blog post on [RAG and Access Control: Where Do You Start?](https://auth0.com/blog/rag-and-access-control-where-do-you-start/).

<include
 src="LinkCard"
 title="RAG and Access Control: Where Do You Start?"
 link="https://auth0.com/blog/rag-and-access-control-where-do-you-start/"
 description="Learn how to get started with Okta FGA for a RAG application."
 img="https://images.ctfassets.net/23aumh6u8s0i/79NCborGcFIrAMeaV7G8oi/f9c588c2d05f0828d447e72e1fe825cc/Latam01.jpg"
/>

## Implementation: Step-by-Step

Below is a sample setup in Python. We’ll keep it simple so you can see the big picture. Feel free to adapt for your chosen LLM or a more robust data store.

### Set Up Prerequisites

To follow this tutorial and secure your application, you’ll need the following:

* Python 3.8.1 or newer.
* An Okta FGA account. If you don’t have one, you can [create one for free](https://dashboard.fga.dev/).
* An [OpenAI account and API key](https://platform.openai.com/).

### Download and install the sample code

To get started, clone the[ auth0-ai-samples](https://a0.to/auth0-ai-samples) repository from GitHub:

```
git clone https://github.com/auth0-samples/auth0-ai-samples.git
cd auth0-ai-samples/authorization-for-rag/langchain-python
# Create a virtual env
python -m venv venv
# Activate the virtual env
source ./venv/bin/activate
# Install dependencies
pip install -r requirements.txt
```

The application is written in Python and is structured as follows:

* `main.py` &mdash; The main entry point of the application, and it is where we define the RAG pipeline
* `docs/*.md` &mdash; Sample markdown files to be used as context for the LLM. There are two types of docs, public and private. Private documents are only accessible to certain individuals.
* `helpers/memory_store.py` &mdash; Creates an in-memory vector store that acts as the base retriever in the chain.
* `helpers/read_documents.py` &mdash; Utility to read the markdown files from the `docs` folder.
* `scripts/fga_init.py` &mdash; Utility to initialize the OktaFGA authorization model and sample data.

### RAG Pipeline

The `main.py` file defines the RAG pipeline using `Langchain` to interact with the underlying LLM model and retrieve data from our context. In your project, your data may be sourced from different platforms and systems, make sure you check the proper documentation about [loaders in the Langchain ecosystem](https://python.langchain.com/v0.1/docs/modules/data_connection/).

The following diagram represents the RAG architecture we are defining:

![LangChain RAG architecture](https://images.ctfassets.net/23aumh6u8s0i/4ReiQ2qnjzYRR18KujkHwe/4c4738866ad275b26aed2d7b9c8d3661/langchain-rag.png)

Now let’s talk Python:

```python
class RAG:
    def __init__(self):
        documents = read_documents()
        self.vector_store = MemoryStore.from_documents(documents)
        self.prompt = ChatPromptTemplate.from_template(
            """You are an assistant for question-answering tasks. Use the following pieces of retrieved context to answer the question. If you don't know the answer, just say that you don't know. Use three sentences maximum and keep the answer concise.\\nQuestion: {question}\\nContext: {context}\\nAnswer:"""
        )

        self.llm = ChatOpenAI(model="gpt-4o-mini")

    def query(self, user_id: str, question: str):
        chain = (
            {
                "context": FGARetriever(
                    retriever=self.vector_store.as_retriever(),
                    build_query=lambda doc: ClientBatchCheckItem(
                        user=f"user:{user_id}",
                        object=f"doc:{doc.metadata.get('id')}",
                        relation="viewer",
                    ),
                ),
                "question": RunnablePassthrough(),
            }
            | self.prompt
            | self.llm
            | StrOutputParser()
        )

        return chain.invoke(question)
```

Let’s break that down.

The `RAG` class first initializes a vector store and reads the documents using the helper functions. It also defines a system prompt for our use case and the LLM model in use, in our case, `gpt-40-mini`.

The class also defines a method query that builds the chain by piping the `FGARetriever` instance with the prompt and the LLM model. `FGARetriever` is provided by the [Auth0 AI SDK for Python](https://github.com/auth0-lab/auth0-ai-python).

The `FGARetriever` is designed to abstract the base retriever from the FGA query logic. The `build_query` argument lets us specify how to query our FGA model, in this case, by asking if the user is a viewer of the document.

```python
build_query=lambda doc: ClientBatchCheckItem(
    user=f"user:{user_id}",
    object=f"doc:{doc.metadata.get('id')}",
    relation="viewer",
),
```

With this design, you can plug any Langchain retriever, combined with checks for any FGA model query.

### Create an OktaFGA Account

If you already have an [Auth0 account](https://auth0.com/), you can use the same credentials to log in to the Okta FGA dashboard at [https://dashboard.fga.dev](https://dashboard.fga.dev/). If you don't have an Auth0 account, hop over to [https://dashboard.fga.dev](https://dashboard.fga.dev/) and create a free account.

Once you are logged in, you should see a dashboard similar to the one below.

![The Okta FGA Dashboard getting started page](https://images.ctfassets.net/23aumh6u8s0i/38P8Vu4qsBvCGrZ4ePew3C/090d068c68b785311a00aa788b92579b/fga-get-started.png)

> When you log into the Okta FGA dashboard for the first time, you may be asked to create a new store. This store will serve as the home for your authorization model and all the data the engine requires to make authorization decisions. Simply pick a name and create your store to get started.

### Create an OktaFGA Client

Once you are in the dashboard, you’ll need a client to make API calls to OktaFGA. To create a client, navigate to **Settings**, and in the **Authorized Clients** section, click **Create Client**. Give your client a name, mark all three client permissions, and then click **Create**.

![Create FGA client](https://images.ctfassets.net/23aumh6u8s0i/2KQc8ACR0MDTqftUgUSXpX/5b779bcece07a69ac775de0fc760c208/Uploaded_from_RAG_and_Access_Control__Where_Do_You_Start)

When you create the client, OktaFGA will provide you with some data like a Store ID, a Client ID and a Client Secret. Don’t close that yet, you’ll need those values next.

At the root of the project, there’s a `.env.example` file. Copy the file and paste it as `.env`. Then, open the file and edit the three FGA-related variables with the values provided by OktaFGA. When you are ready, click continue, and the modal will display the values for the missing variables (`FGA_API_URL` and `FGA_API_AUDIENCE`).

At this step, you can also add your [OpenAI API Key](https://help.openai.com/en/articles/4936850-where-do-i-find-my-openai-api-key), which you’ll need to run the demo.

### Configure the OktaFGA model

Now that the application is set up, you can run the provided script to initialize the model and some sample data. To set things up, run:

```
python ./scripts/fga_init.py
```

You can verify that the script worked by navigating to the model explorer page in OktaFGA. The following model should now have been created:

```
model
 schema 1.1

type user

type doc
 relations
   define owner: [user]
   define viewer: [user, user:*]
```

> You can visit the OktaFGA documentation to learn more about [modeling OktaFGA and creating an authorization model](https://docs.fga.dev/modeling).

On top of the model, the script also created two tuples. Tuples in OktaFGA define the relationships between the types.

First, it defined a tuple to give all users access to the public doc:

- **User** :` user:*`
- **Object** : `public-doc`
- **Relation** : `viewer`

Then, it created a second tuple to give the admin user access to the private doc:

- **User** :` user:admin`
- **Object** : `private-doc`
- **Relation** : `viewer`

> You can visit the OktaFGA documentation to learn more about [tuples and how to create them](https://docs.fga.dev/content/getting-started/new-getting-started#add-tuples).

### Query the Chain

Invoke the chain to process a query and generate a response.

```python
rag = RAG()

question = "What is the forecast for ZEKO?"

# Juan only has access to public docs
response = rag.query("juan", question)
print("Response to Juan:", response)

# Admin has access to all docs
response = rag.query("admin", question)
print("Response to Admin:", response)
```

Fantastic! You now know how to build and scale a secure RAG with Python and LangChain. It’s time to test things out.

To run the chain, simply call the `main.py` file:

```
python main.py
```

If you follow the steps, you’ll see a response like the following:

```
Response to Juan: The retrieved context does not provide any specific forecast or predictions for ZEKO (Zeko Advanced Systems Inc.). It mainly outlines the company's mission, technologies, and products without detailing any financial or market forecasts. Therefore, I don't know the forecast for ZEKO.

Response to Admin: The forecast for Zeko Advanced Systems Inc. (ZEKO) for fiscal year 2025 is generally bearish. Projected revenue growth is expected to remain subdued at 2-3%, with net income growth projected at 1-2%, primarily due to margin pressures and competitive challenges. Investors should be cautious, given the potential headwinds the company faces.
```

As you can see, `Juan` couldn’t retrieve any “protected” data, while the user `admin` got an accurate response to the prompt.

## Conclusion

You’ve seen how to build a **secure** RAG system that respects user permissions at the **document level** using **OpenFGA**. This approach prevents data leaks, meets security and compliance requirements, and stays flexible—perfect for businesses dealing with a large pool of sensitive information.

Feel free to adapt this flow for other vector stores, different LLM providers, or your own organizational rules. By coupling RAG’s retrieval power with fine-grained authorization, you’ll build AI-driven apps that are both insightful and safe.

Before you go, we have some great news to share: we are working on more content and sample apps in collaboration with amazing GenAI frameworks like [LlamaIndex](https://www.llamaindex.ai/), [LangChain](https://www.langchain.com/),[ CrewAI](https://www.crewai.com/), [Vercel AI](https://sdk.vercel.ai/), and others. 

[Auth for GenAI](https://a0.to/ai-content) is our upcoming product to help you protect your user's information in GenAI-powered applications.

Make sure to join the [Auth0 Lab Discord server](http://a0.to/auth0-lab-discord) to hear more and ask questions.

Happy coding!

Building a Secure RAG with Python, LangChain, and OpenFGA

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

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

## Role-Based Access Control (RBAC)

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

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

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

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

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

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

### Example use cases for RBAC:

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

## Attribute-Based Access Control (ABAC)

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

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

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

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

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

### Example use cases for ABAC:

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

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

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

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

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

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

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

### Example use cases for ReBAC:

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

## Summary

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

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

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

Thanks for reading!

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

Kapil Patil

Sr. Partner Solutions Technical Architect

Discover how combining AWS Lambda Authorizers with Okta FGA can strengthen your API security. This approach ensures precise, scalable access management across your applications with minimal overhead.

Streamlining API Security with AWS Lambda Authorizers and Okta FGA

andres

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

Product Manager

Andrés Aguiar

Now, you can deploy Okta FGA in several AWS regions with high availability and requests per second.

We are thrilled to announce that [Okta Fine Grained Authorization](https://fga.dev/) (FGA) is now available as an AWS private cloud deployment option.

Authorization is where Authentication was a decade ago. We aim to simplify Authorization for developers, just as we did with Authentication. In early March, we made significant progress toward this goal by [launching Okta Fine Grained Authorization](https://www.okta.com/blog/2024/03/setting-the-bar-for-authz-okta-fine-grained-authorization-is-now-generally-available/). Okta FGA is an authorization service that enables developers to implement centralized, flexible, scalable, and easy-to-use authorization.

Okta FGA has two deployment options: public cloud and private cloud. The public cloud option is a multi-tenant SaaS service available in three geographies: the United States, Europe, and Australia, offering a highly available multi-region deployment. The private cloud option, on the other hand, is tailored for enterprises seeking dedicated resources. Okta FGA Private Cloud [leverages the same architecture principles](https://auth0.com/blog/securing-auth0s-new-private-cloud-platform/) that have been battle-tested with Auth0 for over two years.

**Benefits of Running Okta FGA in Private Cloud**

* **Higher RPS**: Private cloud instances are optimized for high request-per-second (RPS) performance, scaling up to five times the average RPS based on your application’s needs. 
* **Data Residency and Compliance**: Deploy your Private Cloud environment in any AWS region to help meet specific data residency and compliance requirements. Initial regions include the US, Germany, Ireland, the UK, France, Japan, India, Singapore, Australia, and Brazil.
* **Reduced Latency**: Choose the AWS region closest to your application servers, which will significantly reduce latency for faster access control checks.
* **Multi-Geography Deployments:** Businesses can replicate the same authorization data across multiple regions worldwide, allowing them to maintain low-latency authorization services even for globally distributed applications. For example, a company can have the same data in the US, EU, and Australia, have their authorization data replicated across all regions, and have their applications routed to the closest region.
* **Automated, Hardened Release:** Benefit from automated weekly releases that are previously validated in Okta’s public cloud deployments.
* **Centralized Management:** Manage both private and public cloud instances seamlessly from the Okta FGA dashboard.

The availability of Okta FGA in Private Cloud on AWS marks another significant milestone in our vision of running Okta FGA across all major cloud providers and regions. Stay tuned for further updates, and [Contact Us](https://auth0.com/contact-us?place=header&type=button&text=contact%20sales) to learn more.

Okta Fine Grained Authorization is now Available in Private Cloud on AWS

Sam4-square

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

Principal Developer Advocate

Sam Bellen

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

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

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

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

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

## Role-Based Access Control (RBAC)

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

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

```
guest: [
  view:post
]

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

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

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

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

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

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

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

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

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

### Open Policy Agent (OPA)

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

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

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

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

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

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

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

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

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

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

## Relationship-Based Access Control (ReBAC)

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

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

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

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

### OpenFGA 

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

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

### Direct versus indirect relationships

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

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

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

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

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

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

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

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

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

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

## Hybrid Access Control Solutions

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

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

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

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

## Conclusion

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

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

An Overview of Commonly Used  Access Control Paradigms

In this post, we will focus on adding fine-grained authorization to your Next.js application using Okta FGA.

In this post, we will focus on adding fine-grained authorization (FGA) to your Next.js application. We will check for permissions whenever we request or update data. You'll use Okta FGA, a managed solution for making relationship-based access control (ReBAC) decisions. 

This tutorial will explain the steps needed to add a flexible, fine-grained authorization model to your Next.js application.

- Create an [Okta FGA account](https://dashboard.fga.dev)
- Create your first Okta FGA model
- Add the [Open FGA SDK](https://docs.fga.dev/integration/install-sdk) to your codebase, and configure it to use your Okta FGA account
- Check for permissions in your application
- Update the data Okta FGA can use to make decisions when making changes in our application.

## What You'll Be Building 

Together, we'll go through the codebase of a Google Drive-style application that lets users upload images, create folders, and share these images and folders with other users.

The focus of this blog post is not on how to upload files, so we're not going to spend time on this. We're going to have a look at how we can deal with sharing files and folders and make sure each user only sees the files and folders they own or the ones that have been shared with them.

The app is structured as follows:

- The application's pages come from `/src/app/folder/`, `/src/app/shared/`, and `/src/app/login/`.
- Components can be found in `/src/components/`.
- We use Server Actions to pass data to and from the frontend. These actions live in `/src/app/actions.ts`.
- There's a Data Access Layer in place to handle fetching and writing data to your Vercel KV store and to upload the files to `/upload/`. The code for the Data Access Layer can be found in `/src/data`.
- The code in `/src/store/` helps us communicate with the Vercel KV since you'll need to make multiple requests for certain actions.

All these elements together give us an architecture that looks like this:

![The demo application architecture](https://images.ctfassets.net/23aumh6u8s0i/1OYq4vAITTzTDJhvvFneJW/8ee89cf32dd2a03ba7a79329cb74b8b3/architecture-light.png)

To follow along, you can download the codebase [here](https://github.com/oktadev/fga-drive-example) or run the following command in your terminal.

```bash
git clone git@github.com:oktadev/fga-drive-example.git
```

The application relies on Auth0 and Vercel services. If you haven't already, create an account for them:

 - Auth0, Create a [free Auth0 account](https://auth0.com/signup).
 - Okta FGA uses the same Auth0 account.
 - Vercel KV, create a free Vercel account and a KV store through your [Vercel dashboard](https://vercel.com/dashboard).

## What Is Relationship-Based Access Control

One of the most commonly used approaches to authorization is [Role-Based Access Control (RBAC)](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#What-is-Role-Based-Access-Control--RBAC-), where a role contains a set of permissions and is assigned to each user. This is a simple way of determining what permissions a user has and what actions they should be able to perform within our application.

More complex applications often require a more flexible approach to authorization, where access can be granted on a user and resource level instead of a general resources type, as done with RBAC. Enter Relationship-Based Access Control or ReBAC. Don't let the one extra letter in the acronym fool you; it's a completely different approach to authorization.

Instead of checking a fixed set of permissions assigned to a user via roles, we're going to look at the relationship between a consumer (or group of consumers) and a resource (or group of resources) to determine if they should be able to access a specific resource(s) or perform an action on them. 

Because we're looking at the bigger picture and determining relationships between two entities, these relationships often don't need to be explicitly defined.

For example, if a user belongs to a group, it is enough to grant that group access, and all its members will automatically be granted access. The same is true for a group of resources. If a user has access to, for example, a folder, they should automatically get access to all files within that folder without explicitly defining these relationships. These are called indirect relationships as opposed to direct ones.

## What Is Okta FGA

[Okta FGA](https://fga.dev) is a managed solution by Okta that helps you deal with complex authorization decisions in your application. It uses the OpenFGA modeling language (DSL) and decision engine, designed by Okta and adopted by the Cloud Native Computing Foundation (CNCF).

If you prefer to set up your own instance of OpenFGA, follow the ["Setup OpenFGA"](https://openfga.dev/docs/getting-started/setup-openfga/overview) document.

Okta FGA provides a set of APIs that let you check for permissions or add more data to the decision engine whenever data changes in your application so the decisions can stay up to date.

The decision engine can check for existing relationships between users and objects, but a user should not always be seen as a literal application user. For example, when checking if a folder is the parent of a file, the parent folder is the user, `parent` is the relation, and the file is the object. Therefore, in this guide, I will often refer to the user in the context of an Okta FGA check as a consumer and the object as a resource.

## Create an Okta FGA Account

Good news! If you already have an Auth0 account, you can use the same credentials to log in to the Okta FGA dashboard at [https://dashboard.fga.dev](https://dashboard.fga.dev). If you don't have an Auth0 account, hop over to [https://dashboard.fga.dev](https://dashboard.fga.dev) and create a free account.

Once you are logged in, you should see a dashboard similar to the one below.


![The Okta FGA Dashboard getting started page](https://images.ctfassets.net/23aumh6u8s0i/38P8Vu4qsBvCGrZ4ePew3C/090d068c68b785311a00aa788b92579b/fga-get-started.png)

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  If this is the first time you log into the Okta FGA dashboard, you might be prompted to create a new store. This store will house your authorization model, together with all the data the engine needs to make authorization decisions. Go ahead and choose a name and create a new store.
</div>

## Create Your Authorization Model

Okta FGA uses an authorization model to determine all possible relationships it should consider when making a decision. You'll navigate to the Model Explorer page in our dashboard and add the following model to the model editor. Don't forget to hit save!

![The Okta FGA Dashboard model page](https://images.ctfassets.net/23aumh6u8s0i/4SVEzhIEkv6khWhSGmFhTj/c9b9a233ad6db70fba0836e59a55b983/fga-model.png)

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  Check out the [Okta FGA Playground](https://play.fga.dev) to play around with the model editor or see some example models for applications like Google Drive, GitHub, or Slack.
</div>

```bash
model
  schema 1.1

type user

type file
  relations
    define can_delete: owner or owner from parent
    define can_share: owner or owner from parent
    define can_view: viewer or owner or viewer from parent
    define can_write: owner or owner from parent
    define is_owned: owner
    define is_shared: can_view but not owner
    define owner: [user]
    define parent: [folder]
    define viewer: [user, user:*]

type folder
  relations
    define can_create_file: owner or owner from parent
    define can_create_folder: owner or owner from parent
    define can_share: owner or owner from parent
    define can_view: viewer or owner or viewer from parent
    define owner: [user]
    define parent: [folder]
    define viewer: [user, user:*] or owner or viewer from parent
```

When you look at this model, you'll notice you defined three types: `user`, `file`, and `folder`. You'll be able to assign relationships between these types. For example, a `user` can be an `owner` or `viewer` of a `file` or a `folder` can be a `parent` of a file (or folder, when nesting folders).

You have also defined some permissions related to actions that can be performed on your types, like `can_view` or `can_share` for the file resource type. It's sometimes more future-proof to create relations like this, so if you expand your model in the future, your application can continue to check for these, even if their definition changes. 

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
More information about the Google Drive model can be found in [our documentation](https://docs.fga.dev/modeling/advanced/use-cases/gdrive ).
</div>

With your authorization model in place, Okta FGA has half of what it needs to make decisions. The other half is data on your actual relationships, such as which user owns which file or which folder is a parent of which file. You'll do this in our application code whenever you create a new file or folder or share one of them. But first, let's set up the OpenFGA SDK.


## Install the SDK

To install the OpenFGA Node.js SDK, you'll run the following command in your terminal.

```bash
npm install @openfga/sdk
```

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  You use the OpenFGA SDK to connect to your Okta FGA instance. Both use the same engine and API endpoints and are interchangeable at this point.
</div>

Once installed, you can create a new OpenFGA client in your codebase. You'll find the client in `/src/app/authorization.ts`, and it looks something like this:

```typescript
// [ 📄 /src/app/authorization.ts ]

const fgaClient = new OpenFgaClient({
  apiUrl: process.env.FGA_API_URL,
  storeId: process.env.FGA_STORE_ID,
  authorizationModelId: process.env.FGA_AUTHORIZATION_MODEL_ID,
  credentials: {
    method: CredentialsMethod.ClientCredentials,
    config: {
      apiTokenIssuer: process.env.FGA_API_TOKEN_ISSUER as string,
      apiAudience: process.env.FGA_API_AUDIENCE as string,
      clientId: process.env.FGA_CLIENT_ID as string,
      clientSecret: process.env.FGA_CLIENT_SECRET as string,
    },
  },
});
```

The client needs some details to connect to our Okta FGA tenant, which you can add to the `.env.local` file. You'll find these details on the settings page of your Okta FGA dashboard. If you haven't created a set of API credentials before, you can also do this on the settings page.

- `apiUrl`: The url to your Okta FGA in the form of `https://api.<region>1.fga.dev`
- `storeId`: Found in your Okta FGA Dashboard 
- `authorizationModelId`: Found in your Okta FGA Dashboard, this changes with each update to your model 
- `apiTokenIssuer`: This is currently always `auth.fga.dev` when using Okta FGA 
- `apiAudience`: The same as your `apiUrl` with a trailing slash `/`
- `clientId` & `clientSecret`: Can be found in your Okta FGA Dashboard

The SDK exposes a lot of helpful methods to help you interact with Open FGA, but for this example, you'll focus on these two:

- `fgaClient.check()` checks if there's a relationship between a consumer and a resource; for example, can a user view a certain file.
- `fgaClient.writeTuples()` can write new tuples containing data about specific relationships to our OpenFGA store. You'll use this whenever we create a new file, for example.

When you dive deep into the `/src/app/authorization.ts` file, you'll notice there are some helper methods, but in the end, most of these use one of the two functions above.


## Check For A Relationship

When your application requests data, adds more data, or changes existing data, you want to ensure that these actions are actually allowed. 

Next.js [recommends using a Data Access Layer (DAL)](https://nextjs.org/docs/app/building-your-application/authentication#authorization) to manage data being pulled from or written to your database or data store. This happens to be the ideal location to check if the current user is Authenticated and Authorized for each action. You can find the Data Access Layer in `/src/data`.

The OpenFGA exposes the [`check()`](https://www.npmjs.com/package/@openfga/sdk#check) and [`batchCheck()`](https://www.npmjs.com/package/@openfga/sdk#batch-check) methods to check for a relationship before we perform the actions above.

For example, when you request a file, you'll want to make sure that the current user is allowed to see it. Your authorization model defined a relation `can_view` that specified that either a user that has a `viewer` or `owner` relationship defined to the file or a user that is the owner of a parent folder of the file should be able to view the file. 

So let's check for the `can_view` relationship using the `check()` method. 

```typescript
// [ 📄 /src/data/files.ts ]

export async function getFileDTO(
  fileId: string,
): Promise<{ file?: StoredFile; error?: unknown }> {
  try {
    if (await !isAuthenticated()) {
      return { error: "Unauthorized" };
    }

    const userId = await getUserId();
    // 👇 Check for a "can_view" relation in Okta FGA
    const { allowed } = await fgaClient.check({
      user: `user:${userId}`,
      relation: "can_view",
      object: `file:${fileId}`,
    });
    // 👆

    if (!allowed) {
      return { error: "Forbidden" };
    }

    const file = await getFileFromStore(fileId);

    if (file) {
      return { file };
    }

    return { error: "No file found" };
  } catch (error) {
    return { error };
  }
}
```

Here, you're checking if a user has a `can_view` relationship to a specific file. The `check()` method will return an object containing the decision as an `allowed` property.

## Create a New Relationship Tuple

Whenever you add, update, or delete some of the data your application works with, you want to make sure your Okta FGA instance knows about these changes so it can continue to make accurate decisions. You do this by adding or deleting tuples from the Okta FGA Store.

Whenever a user adds a new file or folder, you'll notice we create 2 new tuples, e.g., `/src/data/files.ts` line `188`.

The first tuple defines the current user as the owner of the file or folder. The second tuple sets the parent folder as the parent of a new file or folder. For example

```typescript
// [ 📄 /src/data/files.ts ]

export async function uploadFileDTO(
  parent: string,
  file: File,
): Promise<{ files?: Array<StoredFile>; error?: unknown }> {
  try {
    //...
    await writeFile(filePath, fileBuffer);
    const files = await createFileInStore(fileId, parent, uploadedFile);

    if (files) {
      // 👇 write new tuples to Okta FGA
      await fgaClient.writeTuples([
        {
          user: `user:${userId}`,
          relation: "owner",
          object: `file:${fileId}`,
        },
        { 
          user: `folder:${parent}`,
          relation: "parent",
          object: `file:${fileId}`,
        },
      ]);
      // 👆
      return { files };
    }

    return { error: "No files uploaded" };
  } catch (error) {
    return { error };
  }
}
```

From this point onward, each check to make sure our user can view this file will return true.

Whenever a user decides to share a file or folder with another user, you also write a new tuple like: 

```typescript
// [ 📄 /src/data/files.ts ]

export async function shareFileDTO(
  file: string,
  email: string,
): Promise<{ file?: string; error?: unknown }> {
  try {
    ...

    try {
      // Check the Auth0 management API for a user with the given email address
      const { data } = await auth0ManagementClient.usersByEmail.getByEmail({
        email,
        fields: "user_id",
      });

      // No known user with the email address, return an error
      if (data.length === 0) {
        return { error: "A user with this email address does not exist." };
      }

      // 👇 Write a new tuple to Okta FGA
      await fgaClient.writeTuples([
        {
          user: `user:${data[0].user_id}`,
          relation: "viewer",
          object: `file:${file}`,
        },
      ]);
      // 👆

      return { file };
    } catch (error) {
      return { error };
    }
  } catch (error) {
    return { error };
  }
}
```

Once this tuple has been written to your store, a check for a relation `can_view` between the user with the passed `userId`, and this file will return true.

You can view and manage all created tuples on the tuple management page of your Okta FGA dashboard.

![The Okta FGA Dashboard tuples manager page](https://images.ctfassets.net/23aumh6u8s0i/2MiUxTxBwFkUZEGP4Ryld0/fea080ec24342ff12b81b2a11c2b0f31/fga-tuples.png)

## List Objects With A Certain Relationship

On the `/shared` page, you'd like to show all files shared with you. The OpenFGA SDK has a convenient method that can list all objects with a certain relation. In your case, you're interested in all files that have a relation of `is_shared` to your user.

You can call the `listObjects()` method to get a list of shared file IDs that you can then fetch from your data store.

```typescript
// [ 📄 /src/data/files.ts ]

export async function getAllSharedFilesDTO(): Promise<{
  files?: Array<ReadableStoredFile>;
  error?: unknown;
}> {
  try {
    ...
    // 👇 List all files with an "is_shared" relation
    const sharedFiles = await fgaClient.listObjects({
      user: `user:${userId}`,
      relation: "is_shared",
      type: "file",
    });
    // 👆 
    ...
  } catch (error) {
    console.error(error);
    return { error: "Something went wrong." };
  }
}
```

## Next Steps

You've successfully implemented fine-grained authorization into your Next.js application. You can check for relationships between resources and consumers and create new tuples that inform Okta FGA about new or changed relationships.

Next, you can play around with the authorization model and adapt it to your needs, look at [conditional relations](https://docs.fga.dev/modeling/basics/conditions), or even create [context-aware relations](https://docs.fga.dev/modeling/basics/contextual-time-based-authorization).

Fine-Grained Authorization in your Next.js application using Okta FGA

Okta FGA achieves unprecedented scalability, paving the way for global authorization systems.

We believe that [Okta Fine Grained Authorization](https://fga.dev) (FGA) will fundamentally change how applications are going to be built over the next decade. At Okta, we aim to solve authorization for both application builders and workforce IT administrators, and FGA is a key piece of that strategy.

Scalability is crucial when designing a global-scale authorization system. It must be capable of delivering the performance and capacity expected from top-tier cloud services, like modern distributed databases. An authorization system capable of supporting a global scale must:

- Be highly available,
- Scale to support the most visited websites in the world,
- Provide low latency, as every millisecond you spend in authorization will impact the application’s overall latency,
- Be able to store a very large amount of data.

This [Google Zanzibar](https://research.google/pubs/pub48190/) paper describes how Google achieves those goals. We built FGA with these goals in mind, and our early tests of the Okta FGA validated that it could handle anything our beta and early access customers could throw at it.

As FGA gained traction among customers, we realized that we needed to push FGA even further to prove out this scale. 

So, we decided to run a test with **1 million Requests per Second (RPS)** and **100 billion relationship tuples** to evaluate how the system behaves. 

## Okta FGA Primer : Model + Relationship Tuples

When implementing authorization using Okta FGA, you need to define an authorization model that describes the different entities in your system that are relevant when making authorization decisions and provide the data required to instantiate the model in the form of relationship tuples.

For example, in the model below, we define groups that can contain users, documents that can have an owner, and viewers that can point to specific users or all members of a specific group:

```yaml
type user
type group
  relations
   define member : [user]

type document
 relations

   define owner : [user]
   define viewer : [user, group#member]
```

Relationship tuples would look like:

| user                   | relation | object              |
| ---------------------- | -------- | ------------------- |
| user:anne              | member   | group:marketing     |
| user:peter             | owner    | document:sales-plan |
| group:marketing#member | viewer   | document:sales-plan |

FGA defines an API method called `Check()` that will let you ask the system if a user is related to an object in a specific way. 

For example, we can call `Check(user:anne, viewer, document:sales-plan)` and we’ll get `“{ allowed: true }”` as a result, given `anne` is a member of the `marketing` group, and their members are related to the `sales-plan` document as viewers.

If you want to learn more, check out how to model with Okta FGA [here](https://docs.fga.dev/modeling).

## Modeling Authorization

When using FGA, the performance characteristics of a specific implementation will depend on the authorization model and relationship tuples in the system. 

The flexibility of FGA means that customers with varying use cases, traffic, and business models are able to harness the full power of FGA. In initial implementations, we’ve seen that customers with a Business-to-Business (B2B) use case tend to have more complex models but with far fewer active users and less traffic. And we’ve seen that customers with a Business-to-Consumer (B2C) use case tend to have less complex requirements but with more data, active users, and traffic. We decided to target these B2C use cases for our performance testing since these are the businesses that are more likely to require a scale of 1 million RPS and 100 billion tuples.

We modeled a social network where users can post content and other users can interact with it. One example of this would be publishing a tweet and commenting on it. The model is described below:

```yaml
type user
  relations
  # Users can have followers, can block specific users, 
  # and can decide if they are visible to all users or just to their followers
  define _self: [user]
  define follower: [user]
  define blocked: [user]
  define visibility: [user:*, user#follower]
  define viewer: visibility but not blocked
  # User profiles can be viewed by the user itself or by the users who have access to their profile
  define can_view: _self or viewer

type content
  relations 
  # Content is owned by the user that published it
  define owner: [user]

  # The content can be visible for anyone or just their followers, for users that are not blocked, and by the owner itself
  define visibility: [user:*, user#follower]
  define viewer: visibility but not blocked from the owner
  define can_view: owner or viewer

type interaction
  relations
  # Content iterations (e.g., comments) have a creator and a content piece as their parent
  define creator: [user]
  define parent: [content]
  # interactions can be viewed if the user can view the creator's profile and the content itself or if they are the creator of the interaction
  define viewer: can_view from creator and can_view from parent
  define can_view: creator or viewer
```

After defining the model, we had to decide how to distribute the relationship tuples in the system. We decided to use a [Pareto distribution](https://en.wikipedia.org/wiki/Pareto_distribution) where:

- 20% of users are generating 80% of content, and 80% of users are generating 20% of content
- Similarly, 20% of users are doing 80% of the interaction, and 80% of users are doing 20% of the interaction

The tests focused on the `Check()` endpoint because this endpoint is the one that will be called more often and have the most impact on the customer's applications. We checked if a user is able to view specific content, a specific user profile, or a specific interaction (e.g., `Check(user:john, can_view, interaction:1)` ).

## Modeling User Activity

Another critical decision point on how to perform the test was how to model user activity.

FGA has a cache that is set to 10 seconds. If we decide that a very small set of users is going to be active, we’d be able to serve all the requests from the cache. That would make it very easy to misrepresent the test results, as serving everything from memory would only happen in very specific use cases and won’t take into consideration the execution paths that require database access. 

We decided to run the tests in three ways:

- Disabling the caches
- With a 50% cache ratio, which seems realistic based on what we observed as an average ratio across all of our customers.
- With a 75% cache ratio, assuming that for a specific customer, ratios can be higher.

## One Million RPS and Beyond

We were very happy with the results and achieved the outcome we hoped for with only minor tweaks to the product.

We allocated three weeks to complete it, and most of the time was spent on generating the dataset, importing them into the database, and making sure we could launch all the clients that called FGA API. 

We completed the test run in just two days without any significant adjustments in our code. 

The tests ran for over 10 minutes and got 1.05M RPS. The images below are from our DataDog dashboard when we ran the tests with 0% cache ratio:

![Request rate received in FGA performance test](https://images.ctfassets.net/23aumh6u8s0i/2aWUERQeZCzKOa7FZUHB3O/cbd911fbacf051c2683221b78e032ca2/fga-rps-performance.png)

![Latency in FGA performance test](https://images.ctfassets.net/23aumh6u8s0i/D14o99yPNCvvNpFlDMDk9/c11f56a116346ee36e0980b48157eed4/fga-latency-performance.png)

The metrics above show that 50% of the calls were completed in up to 11.9 ms, 95% were completed in less than 19.5 ms, and 99% of them were completed in less than 38.5 ms.

We incrementally increased the load while executing the test, and we saw the number of FGA instances increase linearly, maintaining the latency within the same range. We felt confident that we could go way beyond 1M RPS, but we had to stop somewhere 🙂.

When running the tests with caching, the latency decreased significantly, and the number of Okta FGA nodes running too:

<style>
  table {
    width: 100%;
    border-collapse: collapse;
    font-size: 15px;
  }
  table, td, th {
    border: 1px solid;
  }
  table th {
    background-color:#eeeee4;
  }
  td {
    padding: 5px;
    text-align: center;
  }
</style>

| Cache Ratio | RPS per Okta FGA Instance (ECS Fargate 16 vCPU 32GB) | P95 Latency |
| ----------- | ---------------------------------------------------- | ----------- |
| 0%          | 3,500                                                | 19.5 ms     |
| 50%         | 6,000                                                | 9.4 ms      |
| 75%         | 18,000                                               | 5 ms        |

## Okta FGA and You

We were thrilled to have tangible proof that FGA can support the global scale it was designed for. FGA provides a highly flexible, highly available, and scalable solution to implement authorization, supported by a company that is a trusted leader in the identity space.

You can try Okta FGA today by signing up for an evaluation account [here](https://fga.dev). If you want to use it in production, you can apply to our Limited Early Access Program by reaching out to your technical account manager or account executive. 

"okta fga"