A Step-by-Step Guide to Securing Amazon Bedrock Agents with Auth0

I'm a developer looking to manage IdP (Okta) operations with a GenAI app built using Amazon Bedrock. I want to see if I can use Auth for GenAI to secure my GenAI app in the following ways:

• Standard Secure Login: I want to offer users a secure login experience through the IdP of their choice using Auth for GenAI, without building custom authentication logic.

• Identity-Based API Access: The agent should interact with Okta APIs using the logged-in user’s identity, not static credentials — ensuring accountability and traceability.

• Authorization-Aware Actions: Before performing any action on Okta resources, the agent must check if the user is authorized to make real-time changes.

• Background Task Support: Some Okta operations may take time. The agent should support asynchronous actions while preserving user context, so the experience remains smooth and secure.

This scenario lays the foundation for building a secure, identity-aware Amazon Bedrock agent that automates Okta IAM operations using Auth for GenAI. In the remainder of this blog post, we’ll explain how Auth for GenAI enables developers to build secure, production-ready Generative AI applications with robust identity and access controls.

This post will describe the step-by-step approach to securing your Amazon Bedrock agent with Auth for GenAI service offerings.

Before we start with the solution and integration steps, we will summarize:

• Summary of Auth for GenAI service offerings
• Amazon Bedrock Agent and its components
• Solution prerequisites
• The Core Challenges of AI Agent Authentication

Auth for GenAI

Auth for GenAI is an offering from Auth0 designed for developers building Generative AI applications such as chatbots and AI agents. It gives you the essential identity and access management (IAM) capabilities needed to build secure GenAI apps with confidence.

As developers integrate GenAI into their applications, we’ve identified four key identity requirements for supporting AI agents and ensuring secure interactions. Auth for GenAI is built to help you focus on building great user experiences while we handle the hard parts of identity and access.

The following are the four main pillars of Auth for GenAI service.

1. User Authentication

   In an AI-driven app, user identity matters. Whether a human is chatting with an AI assistant or initiating a complex workflow, authentication remains essential. Auth for GenAI provides secure user login services, so AI agents know who initiated the task or conversation and can personalize and protect accordingly.

2. Token Vault: Call APIs on Users’ Behalf

   AI agents rely on APIs. But they must do so securely on behalf of users, often across multiple systems. Auth for GenAI offers OAuth-based delegation, so your agent can act on behalf of a user to third-party APIs without compromising user security.

3. Fine-Grained Authorization (FGA): Authorization for data retrieval

   GenAI apps use Retrieval-Augmented Generation (RAG) to feed context from internal or external systems into the model. However, not all data is meant for all users. Auth for GenAI ensures fine-grained access control over what data can be retrieved and presented based on the user’s permissions, helping prevent data leaks.

4. Async Authorization

   AI agents often operate beyond a synchronous request/response cycle. Auth for GenAI supports asynchronous interactions, letting agents securely maintain identity context over time in the background.

Together, these capabilities give developers the building blocks to build secure, scalable AI apps with identity handled correctly. Learn more about

We will present a practical example of how to use Auth for GenAI services in an AI agent.

Amazon Bedrock Agent

Amazon Bedrock is a powerful new way to build AI-powered apps using a fully managed orchestration layer without provisioning infrastructure.

An Amazon Bedrock Agent is a collection of modular components that process user requests, reason through tasks, and interact with your backend systems. Here's a breakdown of the core building blocks of an Amazon Bedrock Agent:

1. LLM’s (Foundation Model)

LLM’s (Large Language Model), like Anthropic Claude, Meta Llama, or Amazon Titan, are available via Amazon Bedrock. These LLM’s power the agent’s understanding and generation of language for user requests, generating structured API calls or composing natural responses.

1. Prompt Templates

Amazon Bedrock Agents use prompt templates to guide how the LLM interprets inputs and produces outputs. Templates include: System instructions to frame the agent’s role.

These prompts ensure your agent behaves consistently, respects task boundaries, and maintains a trustworthy tone.

1. Action Groups

Action Groups are how agents perform real-world tasks. Each group defines a set of functions or APIs the agent can call. Developers define each action’s name, description, input schema, and optionally map it to a Lambda function. Amazon Bedrock generates function-calling instructions, and the LLM learns when and how to invoke these actions based on user input.

1. AWS Lambda

AWS Lambda functions are where custom business logic runs. When an agent decides to invoke an action, it calls the associated AWS Lambda function. Developers can write these functions in any supported language. Lambdas give you a flexible and scalable way to extend the agent’s abilities.

Solution Prerequisites:

Before starting, you need an Auth for GenAI, an Auth0 FGA, and an AWS Account.

Creating an Auth for GenAI Account: If you are new to Auth0, create an account to start using, or if you already have an account, log in using your existing Auth0 credentials.

Creating an AWS Account: If you already have an AWS account, you can use the same credentials to log in to the AWS Console; if you don't have an AWS account, you can create one here.

Creating an Auth0 FGA Account: If you already have an Auth0 account, you can use the same credentials to log in to the Auth0 FGA dashboard at https://dashboard.fga.dev. If you don't have an Auth0 account, hop over to https://dashboard.fga.dev and create a free account.

Authentication and Authorization for AI agents.

There is no standardized blueprint for building AI agents securely today. Without the right security, you risk adding a whole new attack surface to your application with agentic AI. AI applications now handle sensitive user data and are not just processing the information; they interact with APIs, automate decisions, and act on users’ behalf. These agents need least privileged access to user data, non-static access credentials, and fine-grained access control.

Developing secure AI agents is challenging due to a lack of standards and new attack surfaces. GenAI applications handle sensitive user data, interact with APIs, and automate decisions, necessitating fine-grained, non-static, and least-privileged access. Common misconceptions about GenAI security include:

• AI agents don't inherently "know" the user
• API keys are not suitable for agents due to lack of per-user context
• Prompt engineering alone isn't enough for LLM safety
• "Yes" does not equal sufficient consent for sensitive actions
• Role-based access control is ineffective given dynamic information discovery
• LLMs should never handle credentials.

These misconceptions lead to unauthorized data access, stale permissions, compliance gaps, weak authorization, secrets leakage, and privacy exposure. Current developer practices, whether intentional or not, hinder the production-level deployment of AI agents." (Active voice and more direct).

Architecture of Auth0-Secured Bedrock Agents

This document outlines the process by which Auth for GenAI, integrated with Amazon Bedrock, enables applications and agents to interact with Okta resources on behalf of a user.

1. A user logs into the application using Auth0 login experience via an external Identity Provider (IdP).
2. Upon successful login, Auth for GenAI securely stores federated tokens (Access and Refresh tokens) in a token vault. These stored tokens allow applications and agents to act on the user's behalf when interacting with Okta resources.
3. The application leverages an agent configured within Amazon Bedrock to process user inputs and queries.
   
   • The application utilizes AWS SDKs to interact with Amazon Bedrock.
   • User requests are transmitted to the Amazon Bedrock agent, which determines the appropriate tool and generates the correct response.
   • Using the LLM and prompt template, the agent determines which Action Group to use.
4. The agent then invokes the Action Group / Lambda function.
5. Before executing, the Lambda code performs an authorization decision using the Fine-Grained Authorization (FGA) module.
6. The Action Group initiates a CIBA (Client-Initiated Backchannel Authorization) flow to support asynchronous authorization.
7. Lambda executes the final operation on the Okta resources as the concluding step. This occurs only after verifying the correct authorization and ensuring that the agent is acting legitimately on behalf of the user.

How to Build it?

Let's explore the solution's components, understanding their interrelations and contributions to securing Amazon Bedrock agents.

We will break our build process into five sections:

Part 1: Configuring Auth0 for Secure Authentication: Covers creating the app, grant types, and enterprise connection.

Part 2: Building the Amazon Bedrock Agent: Covers creating the agent, action groups, and Lambda functions.

Part 3: Setting Up the Supporting AWS Infrastructure: Covers IAM credentials and the DynamoDB table.

Part 4: Implementing Fine-Grained Authorization: Covers the FGA model and tuple configuration.

Part 5: Configuring and Testing the Application: Covers the Flask app setup and test plan.

Part 1: Configuring Auth0 for Secure Authentication

To demonstrate the user experience, we will develop a web application that integrates a Amazon Bedrock agent. This agent will engage with user inquiries and inputs.

• Create an application

After logging in to your Auth0 tenant, navigate to "Applications." Click "+Create Application," then provide a name and select "Regular Web application" in the create application dialog and click Create. The application we will be building is a Python Flask application

• Configure an application

As the next step, choose the application framework; we are going to create this app as a Python application.

The following screen will display sample code to expedite the development process.
Click on Settings screen to access important configuration parameters.

Note down the ClientID, Client Secret, and Domain values; they will be used in the Flask codebase.

Go to the bottom of the section Advanced Settings and click on Grant Types; in here, make sure Token Exchange and CIBA checkboxes are checked

Click Save at the bottom right of the page.

• Creating an enterprise connection

Follow these instructions to create an Okta OIDC connection. Once configured, navigate to your OIDC connection from Authentication-> Enterprise-> OIDC, and ensure offline_scope is enabled.

Go to Applications Tab of the OIDC connection created, and assign the connection to your app created earlier.

Part 2: Building the Amazon Bedrock Agent

• Create an Amazon Bedrock Agent
  Go to the AWS console and select the service Amazon Bedrock. Once inside the console screen, click on Build -> Agents. Click "Create agent." Provide an agent name and a description:

After creating the agent,

1. Retain the default Agent resource role option ("Create and use a new service role"). This action will generate a new AWS role for you.
2. Provide detailed instructions to ensure the agent accurately interprets requests and performs actions precisely. Instructions will allow the agent to adapt to user queries.
3. Proceed to select the model by clicking "Select."Model button.

Next, selecting the model. From the model list, select the AWS LLM model you have access to and then select the mode for your agent. Want to know how to request access to the model? Check here.

To support agent operations, we will be creating two action groups to support the use case:

1. An action group to list Okta User Groups API on behalf of users.
2. An action group to initiate a CIBA flow for users performing elevated actions.

Key considerations for Action Group Setup:

• All the action group changes would be performed in Agent Builder mode; to enter builder mode, click on ‘Edit in Agent Builder.’

Creating an Action Group for Okta APIs using Token Vault

In the Action Groups Section of the Amazon Bedrock agent, click Add. Then enter Name and Details of the Action Group.

Selecting "Quick Create a new Lambda function" from the Action Group Invocation will create a Lambda function within the Action Group.

In the Action Group Function section, enter details about the Action Group Function and click create.

Navigating to this new action group will confirm that the Lambda function has been successfully generated.

The codebase for the newly created action group, which enables Okta Group Access using Auth0 FGA and Token Vault, can be found in this GitHub Repo. This Lambda code refers to another Lambda function, fga_authorizer-bedrock-aws-okta, which can be found in this section. To enable the Action Groups, you must first set up the FGA Lambda function; we will cover this in Part 4 of the build setup.

Important notes in configuring Action Group

• FGA and Action Group Lambda settings must be configured after the FGA authorization model is set up.
• The DynamoDB table name should be configured once the DynamoDB table is created.

Creating an Action Group for CIBA flow

Follow the same process as we discussed in the previous section to create another action group for performing CIBA flow, as described above, and you would notice a new Lambda function has been created.

The codebase for the newly created function CIBA flow can be found in GitHub Repo.

At the end of these steps, you should be able to see a bedrock agent with two action groups.

Create Alias and Version of the Amazon Bedrock agent, and once created, use those values in the Flask application as mentioned. Follow the GitHub code to complete the Lambda Function. Please ensure that each Lambda's IAM roles have sufficient permissions for successful execution.

Important notes in configuring Action Group

• Please use Client Id and client secret from auth0 app configurations in setting up Action Group Lambda function.

Part 3: Setting Up the Supporting AWS Infrastructure

Setting up AWS Credentials

To enable communication between the web application and the Amazon Bedrock agent, AWS credentials are required. These credentials will be utilized within the web application to interact with Amazon Bedrock agents. Begin by navigating to the AWS IAM console, then user, and selecting "Create User."

Enter the Username and click next

Select Permissions; for demo purposes only, I am selecting Admin permission.

Note: It is crucial to emphasize that for a production environment, developers should follow the principle of least privilege and create an IAM role with the minimum required permissions (bedrock: InvokeAgent, dynamodb: GetItem, lambda: InvokeFunction, etc.). This least privilege role can be assigned where the app is hosted.

Click Create User and go to the newly created user and access Security Credentials tab and click Create Access Key

In here, click on "Local code" and then "Next; Add description tag/value and click next

Retrieve and save these credentials immediately, as you will not be able to view the secret access key again. You will be needing these credentials in the Flask App environment variables.

Setting up AWS DynamoDB table:

To integrate Auth0's federated tokens with Amazon Bedrock agent tools, we'll retrieve tokens from Auth0's token vault. A secure approach dictates that session and time values should not be passed to Amazon Bedrock via the session, as sending access tokens to LLM models is insecure.

For this demonstration, federated access tokens will be stored in a DynamoDB table, allowing Amazon Bedrock's Lambda function to securely retrieve them. DynamoDB is used here as a reference and can be substituted with any preferred tool, such as Vault or other caching solutions.

Go to DynamoDB table and click on Create table

In the next dialog; enter table name as “bedrock-sessions” and use Partition key as “session_id”

Part 4: Implementing Fine-Grained Authorization

Authorization Model

Auth0 FGA uses an authorization model to manage all relationships between users and the operations they can perform. This section will demonstrate how an Amazon Bedrock agent can leverage an FGA Model, created for our specific use case, to make authorization decisions based on the logged-in user.

Add the following model to the model editor, and remember to hit the Save button.

 model
 schema 1.1

type user

type group
 relations
   define member: [user]

type okta
 relations
   define read_okta: [user, group#member]

After saving the model, you will see its preview and authorization model.

Go to the Tuple Management section, accessible from the main dashboard, which allows you to define users and their relationships to various application objects.

Click on the Add Tuple button to add relationship data, adding a tuple to demonstrate.

The following tuple represents that user kapil.patil@okta.com can read Okta groups

So far, we have the Okta FGA Authorization Model and all the relationships ready.

Configuring the FGA authorization model:

To configure the Authorized Client for the authorization model, which will help to connect to the application, click on the settings menu of the Authorization model you are working on, and click on “+ Create Client”.

Select the suitable set of permissions your application needs and click Create.

This step creates the credentials required for your app. Make sure to save these values before clicking on the continue button.

To support the Amazon Bedrock agent authorization decision, we will utilize a newly defined authorization model. A separate Lambda function will be created to invoke the FGA authorizer function. This function will evaluate actions Amazon Bedrock takes on behalf of a user and control the execution of those action groups.

Use the codebase from GitHub repository; this FGA authorizer is utilized within the action group to control user permissions for specific operations.

Part 5: Configuring and Testing the Application

Configuring the Flask Application

We have now configured all the necessary components for the demo. So far, we have set up an Auth0 App, an Auth0 FGA model, and AWS resources. The next step is to integrate these elements by configuring our Flask application.

Start by creating a Flask web application using the provided GitHub repository. This application will communicate with the Amazon Bedrock agent you created in earlier steps.

How to Test it?

1. Open the Web App URL in your browser and log in using your Auth0 credentials.
   Expected Result: You are asked for consent and prompted to enroll in MFA via Auth0 Guardian; the login is completed successfully.

2. In a new tab, go to the Auth0 Dashboard, navigate to Security → Multi-factor Auth, and set the MFA policy to "None".
   Expected Result: MFA is now disabled for your account and will not be triggered during future logins. This change will ensure the token vault works as expected.

3. Return to the Web App and verify that the chatbot interface is visible.
   Expected Result: A chatbot UI should load and be ready for interaction.

4. In the chatbot input box, type "Give me Okta groups for a user ?" and send the message. Expected Result: The chatbot should respond with a list of Okta groups associated with your account.

5. In the chatbot, type "How do I reset my password?" and send the message.
   Expected Result: The user gets a prompt on the Guardian app. Upon approving the prompt in the Guardian app, your identity will be confirmed, and the action will be executed. Please note that this action represents a flow and does not actually reset your password.

6. Log into the FGA Console, locate your user entry, and remove the permission to access Okta group data.
   Expected Result: Your access to group information is revoked and no longer valid.

7. Return to the chatbot and ask again, "What are my Okta groups?"
   Expected Result: The chatbot should respond with an "Access Denied" or "Not allowed" message, confirming FGA enforcement is working.

Conclusion

This solution demonstrates the powerful synergy between Auth for GenAI and Amazon Bedrock, enabling the creation of secure and identity-aware AI agents. By leveraging Auth0's robust identity and access management capabilities, including secure user login, API delegation, fine-grained authorization, and asynchronous interaction support, applications built with Amazon Bedrock agents can operate with enhanced security and accountability. This integration ensures that AI agents can act on users' behalf without compromising sensitive data, apply real-time authorization checks, and maintain user context across complex, multi-step operations.

Glossary

Auth for GenAI: An Auth0 offering designed for developers building Generative AI applications, providing essential identity and access management (IAM) capabilities.

AWS Lambda: Serverless compute service where custom business logic runs, invoked by an Amazon Bedrock Agent to execute actions.

CIBA (Client Initiated Backchannel Authorization): An OAuth 2.0 flow that enables an application to initiate an authentication and authorization process in a decoupled manner, often used for asynchronous actions.

DynamoDB: A fully managed, serverless, key-value NoSQL database designed to run high-performance applications at any scale.

Fine-Grained Authorization (FGA): A mechanism for controlling access to data at a very detailed level, ensuring that only authorized users can retrieve and view specific information.

IdP (Identity Provider): A system that creates, maintains, and manages identity information for principals and provides authentication services to applications.

LLM (Large Language Model): A type of artificial intelligence model trained on vast amounts of text data to understand and generate human-like language.

OAuth: An open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites without giving them the passwords.

Okta OIDC connection: A connection in Auth0 that allows users to authenticate using Okta as an OpenID Connect (OIDC) identity provider.

Token Vault: A secure storage mechanism, often within Auth for GenAI, for federated tokens (Access and Refresh tokens) that allows applications and agents to act on a user's behalf.