cameron-pavey

Cameron is a full-stack dev living and working in Melbourne. He's committed himself to the never-ending journey of understanding the intricacies of quality code, developer productivity, and job satisfaction.

Senior Developer

Cameron Pavey

Forcing autonomous software into human user profiles creates massive security risks. Discover how to build a first-class AI agent identity architecture.

AI Agents Are Not Users: Building an Identity Model That Reflects That

Sheena Allen

Sheena Allan is a Product Manager at Auth0, focusing on Organizations and Self-Service Enterprise Configuration products. She drives strategic planning, product roadmaps, and feature development for B2B SaaS.

Product Manager

Sheena Allan

Win the enterprise identity security race. Master the Trust Stack to deliver frictionless onboarding, automated SCIM, and real-time threat remediation.

In our [first episode of *What the SaaS*, we named the identity wall](https://auth0.com/blog/breaking-identity-wall-with-tenancy-as-a-service/): the moment a B2B SaaS company discovers that their consumer-grade auth setup will not survive contact with an enterprise procurement team. In our [second, we laid out the architectural solution, the Organizations model](https://auth0.com/blog/why-robust-organizations-model-is-non-negotiable/), that makes true multi-tenancy possible.

But knowing the right architecture is only half the battle.

The harder question is what happens next because building a robust identity layer is one thing. Getting enterprise customers to trust it, adopt it, and stay protected by it, at speed, at scale, under real-world conditions, is something else entirely.

That is the question I brought to a [powerhouse panel in Episode 3](https://auth0.com/resources/podcasts/what-the-saas-3). Aaron Smalser (Product Architect, Auth0), Scott Miramontes (Senior Director of ISV Ecosystem Growth, Okta), and Sam Rosen (Senior Director of Product, Auth0) joined me to unpack three capabilities that, together, create what I have started calling the Trust Stack: the [Okta Integration Network](https://auth0.com/blog/auth0-powered-apps-okta-integration-network/), [Express Configuration](https://auth0.com/blog/express-configuration-auth0-saas-apps-okta-oin/), and [Universal Logout](https://auth0.com/docs/authenticate/login/logout/universal-logout).

Here is what I took away from the conversation.  

## The Problem Is Bigger Than Onboarding

Sam reframed something early in the conversation that I have not been able to stop thinking about.

The challenge is not just getting enterprise customers set up. It is that the number of identity features they expect is growing, and so is the surface area for things to go wrong.  

>"There are 20 or 30 other identity features coming around the corner that are going to make SaaS companies more and more secure, and the AI threat landscape is only going to make that list get bigger and bigger. The biggest issue for a SaaS vendor starts to become: how do you onboard a customer? How do you get them onto your platform? More importantly, how do you make sure they did it correctly?"

This is the tension at the center of the enterprise identity problem. The more powerful your security posture, the more configuration steps stand between you and the customer who is actually protected. And if they get even one of those steps wrong, the whole thing falls apart.

The Trust Stack is Auth0 and Okta's answer to that tension.  

## The Okta Integration Network: Someone Else Vouches for You

The best analogy Sam offered was the App Store, and it is a good one.

When a user downloads an app from the Apple App Store or Google Play, they do not start from zero. Someone has already vetted that the application is safe, that it meets platform standards, that it was built correctly. Trust is pre-established before the first interaction.

The Okta Integration Network (OIN) works the same way for enterprise software. It is a catalog of thousands of pre-built, pre-vetted integrations between Okta and SaaS applications. And as Scott explained, getting listed there is not just a distribution play, it is a trust signal.  

>"It's really about getting access to the enterprise buyer. If you want to sell to anyone beyond SMBs or early-stage startups, having basic identity security capabilities and making them easy for your customer to onboard become critical."

Scott described a pattern he sees consistently: a SaaS vendor starts with "Sign in with Google," then starts hearing from enterprise prospects that they need support for identity providers like Okta. The conversation then evolves from basic Single Sign-On (SSO) to lifecycle management, to Universal Logout, to more advanced compliance requirements. The OIN is where that entire spectrum lives.

One concrete example stood out. When Scott spoke with a product executive at Slack about their Okta integrations, the feedback was unambiguous: lifecycle management was a game-changer, not just for large customers managing complex org structures, but for smaller ones who needed speed.
  
>"For smaller customers, they're all about speed. Because Slack integrated with Okta, they allowed those smaller customers to onboard and offboard users through a centralized IDP, which allowed them to deploy Slack a lot more quickly."

And there is a standards dividend here too. Because Okta's lifecycle management capability is built on System for Cross-domain Identity Management (SCIM), Slack's investment was not just an Okta integration, it was a capability that now works across the entire SaaS ecosystem.  

## Express Configuration: The "Click and Install" Experience

Even with an OIN listing, there is still a gap. The integration exists. The documentation exists. But IT administrators still have to actually set everything up, often across two different portals, copying and pasting values, hoping nothing gets misconfigured.

Aaron described what that looks like without Express Configuration: 
 
>"A typical manual self-service experience for setting up all these protocols can easily require over 20 steps and copying and pasting data between two portals."

Twenty steps. Each one is a place where something can go wrong, a support ticket waiting to happen, a security misconfiguration that will not surface until it is too late.

Express Configuration collapses that process. It is a fully automated flow that lets an Okta IT administrator configure SSO via OpenID Connect (OIDC), lifecycle management via SCIM, and Universal Logout with Auth0-powered applications, in a few clicks, from within the OIN.

Under the hood, it is secured through Auth0's authentication API using a standard OAuth 2.0 authorization code flow. The IT admin starts the flow in the Okta dashboard, authenticates into Auth0 via Universal Login, grants consent, and Okta uses the resulting access token to configure all the components on their behalf.

The result: an App Store-style "click and install" experience for enterprise identity.

Sam was direct about why this became a priority, and it was not a single customer request. It was pattern recognition. 
 
>"We saw customers struggling with setting up SSO providers. We saw customers struggling with figuring out how to advertise trust... We're one of the few companies that can actually offer that true point-and-click integration. So that was just a logical yes."

The harder push came from looking forward. Standards like Interoperability Profile for Secure Identity in the Enterprise (IPSIE) are coming. The identity configuration surface is only going to grow. Getting customers to "done correctly" once is hard enough. Express Configuration is how you make "done correctly" the default outcome, not the lucky one.  

## Universal Logout: Not an Offboarding Tool. A Security Control.

Universal Logout is easy to undersell. "User leaves the company, their access gets revoked", sure, fine, but that sounds like a lifecycle management problem, and you might already have that covered.

Here is why that framing misses the point.

Aaron explained that Universal Logout is based on the Global Token Revocation standard. Its goal is not just to log someone out of a browser session, it is to revoke everything: sessions, tokens, refresh tokens, across traditional web apps, SPAs, and native apps. 
 
>"The goal is to revoke access everywhere across all modalities and application types."

And the use case that changes the risk conversation is not offboarding. It is this: Okta has a product called Identity Threat Protection that detects active threats in real time, compromised credentials, anomalous behavior, potential insider threats, and can trigger Universal Logout as an automated remediation. Not a ticket. Not a manual process. Immediate, comprehensive session termination, the moment a threat is detected.

That is a security operations tool, not an IT admin convenience.

Sam drove this point home with two stories from his time as an identity consultant. The first involved a global auto manufacturer whose financial and B2B divisions had written session termination requirements directly into their vendor selection criteria. A SaaS vendor that could not meet them got replaced, an 18-month rip-and-replace initiative that cost far more than any single enterprise deal.

The second was in healthcare, where access to patient services portals and medical information portals carried HIPAA obligations and regional regulatory exposure. Sam's team won those deals not on features or price, but on the ability to demonstrate comprehensive session termination.  

>"I was told multiple times that we were selected as a vendor because this thing existed."

## The Superpower Is the Stack, Not Any Single Capability

What I kept coming back to throughout this conversation is that none of these three capabilities are as powerful in isolation as they are together.

The OIN provides the trust signal that opens the enterprise door. Express Configuration helps ensure customers walk through it correctly, without friction, without misconfiguration. Universal Logout ensures that when something goes wrong, and eventually, something always goes wrong, your product can respond in real time.

And the reason this particular stack is hard to replicate is the vertical integration. Auth0 on the application side. Okta on the enterprise Identity Provider (IdP) side. The OIN as connective tissue. Most identity vendors can offer you pieces of this. Very few can offer you the whole system.

As Scott put it: 
* build your identity strategy early
* find a partner who can help you navigate it 
* do not treat it as an afterthought because your enterprise buyers do not.

Being easy to adopt is a competitive advantage. Being able to remediate identity threats in real time is quickly becoming table stakes. The companies that get there first will win enterprise.

To hear the full deep dive into the Trust Stack, listen to the [complete episode of What the SaaS](https://auth0.com/resources/podcasts/what-the-saas-3).


Enterprise Trust Is a Race. Here is How to Win It

andrea-chiarelli

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

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

Principal Developer Advocate

Andrea Chiarelli

Why the code around your LLM matters more than the LLM itself: the architectural insight that changed how I think about AI agent security.

Everyone seems to be building AI agents now. But ask ten developers what an AI agent actually is, and you'll get ten different answers. Some say it is any LLM with tool access. Others define it by the ability to autonomously take actions in the world. A few will point at an existing chatbot and call it an agent.

This definitional vagueness is not just an academic problem. It leads to a security problem. How can you protect a system you cannot describe precisely?

## Looking for an AI Agent Definition

Beyond the generic definitions that emphasize the level of autonomy in making decisions, I'd like to point out a slightly more technical one that I prefer. It comes from [Microsoft](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/#what-is-an-ai-agent) and seems to be quite consistent with the [OWASP definition](https://genai.owasp.org/glossary/):

"*An AI agent is a flexible software program that uses generative AI models to interpret inputs, \[...\] reason through problems, and decide on the most appropriate actions. \[...\] Agents are built on five core components:*

* _ **Generative AI model** serves as the agent's reasoning engine. It processes instructions, integrates tool calls, and generates outputs, either as messages to other agents or as actionable results._
* **Instructions** define the scope, boundaries, and behavioral guidelines for the agent. Clear instructions prevent scope creep and ensure the agent adheres to business rules.*  
* _ **Retrieval** provides the grounding data and context required for accurate responses. Access to relevant, high-quality data is critical for reducing hallucinations and ensuring relevance._  
* _ **Actions** are the functions, APIs, or systems the agent uses to perform tasks. Tools transform the agent from a passive information retriever into an active participant in business processes._ 
* _ **Memory** stores conversation history and state. Memory ensures continuity across interactions, allowing the agent to handle multi-turn conversations and long-running tasks effectively._"

Agents differ from traditional applications, which are based on fixed rules. By dynamically orchestrating workflows according to real-time context, agents gain adaptability that allows them to manage ambiguity and complexity beyond the capability of traditional software.

We can visualize this definition into the following diagram:

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/uKLVsROcv4NHKZZ6QvuTA/9036537f8d4d4dca7deee1e7622eac84/AIAgentDefinitionDiagram.png" alt="Diagram of an AI agent architecture showing the deterministic Agent Core, Tools, and the probabilistic LLM reasoning engine." style="width:100%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>
Aside from input, output, and external resources, the heart of an AI agent is a collection of instructions, the LLM, and the Agent Core.

The LLM is, as we know, the brain of the agent, the component that performs the necessary reasoning and makes decisions. The Agent Core is the software component that orchestrates the interactions between the LLM and the rest of the world. The Agent Core is the code in your Python, JavaScript, C#, etc. application that interacts with the LLM.

Within the Agent Core, I highlighted two components: the Agent Control and the Tools. The Agent Control is the heart of the agent, the part that coordinates all the interactions between the LLM and the external world. The Tools component represents all the functionality made available to the LLM, such as calculation functions, file system access, etc. This component is also the interface to external tools and resources. The combination of the Agent Control and the Tools components builds the Agent Core: just plain old-style code, with no *intelligent* functionality.

Looking at the diagram, we notice two interesting things:

* The two true components of an AI agent are the Agent Core, which is deterministic, and the LLM, which is not deterministic.  
* The Agent Core is the only component that interacts with the LLM. 

These two simple observations are fundamental to understanding the nature of an AI agent and how we can secure it.

## The Two Souls of an AI Agent

The first observation highlights that the two core components of an AI agent are a traditional deterministic application and an LLM, which is not deterministic.

The Agent Core sends the input to the LLM, provides functionalities to it, processes the output, etc. by running deterministic code. You can analyze it, test it, you know how it works and you know that for a given input you will always get the same output.

The LLM model has a different nature: it is not deterministic. Given the same input on two different occasions, a generative AI model may produce different outputs. It can reason in unexpected directions, interpret ambiguous instructions in ways you did not anticipate, and combine information from its context in ways that surprise even the people who built it. This is at the same time the power and the problem with LLMs.

>Saying that LLMs **are not deterministic is not the same as saying it is non-deterministic**. While commonly LLMs are considered to be non-deterministic, this is not correct in computational terms. See [this article to learn why LLMs are not non-deterministic](https://theturingmachine.net/generative-ai-and-non-determinism).

So, in the architecture of an AI agent, we can identify what I call two souls: a **deterministic soul** (the Agent Core) and a **probabilistic soul** (the LLM).

>If you are a philosophy enthusiast, you might notice a certain reference to the dualities of the human soul: from [Plato's myth of the winged chariot](https://en.wikipedia.org/wiki/Phaedrus_(dialogue)#Chariot_allegory) to [St. Augustine](https://en.wikipedia.org/wiki/Augustine_of_Hippo)'s two wills to Nietzsche's distinction between the [Apollonian and Dionysian concepts](https://en.wikipedia.org/wiki/Apollonian_and_Dionysian).<br /><br />
The tension is the same: one controlled, one wild. And the wild one gets all the attention.

Traditional software security is built almost entirely on the assumption of determinism. You know what inputs are valid, you know what outputs to expect, and you can test edge cases exhaustively. *AI agents shatter this assumption*. The probabilistic soul introduces a category of behavior that no test suite can fully cover.

The implication for security follows directly: you cannot secure the model itself. What you can do is **architect the deterministic soul to constrain what the probabilistic soul can reach**.

## The Three Laws of AI Security Applied

Some time ago, I wrote an [article about the three laws of AI security](https://auth0.com/blog/three-laws-ai-security/). Paraphrasing Asimov's three laws of robotics, I defined similar laws to control the less deterministic part of AI. Similar to what I have analyzed in this article, I observed that the fundamental problem in building secure AI-powered applications is [the loss of that control](https://auth0.com/blog/three-laws-ai-security/#The-Control-Problem-with-AI) we have become accustomed to with deterministic software.

Based on the discussion we have had so far, we say that in the architecture of an AI agent there is a component that makes decisions and is not deterministic (LLM) and one that executes orders in a deterministic way (Agent Core).

Paradoxically, the decision-making part is beyond our control: it is not deterministic, we have no tools to predict with certainty whether it will make the decision we expect or not.

But in this scenario we forget one important thing: *it is not only the LLM that makes decisions*. The Agent Core can make decisions as well. And that is not all. Our earlier second observation tells us that the Agent Core is the only component that interacts with the LLM. All the input coming from the user, other agents, external tools, and resources is filtered by the Agent Core before going to the LLM. All the output going to the users, other agents, external tools and resources comes through the Agent Core. **The LLM cannot directly interact with the external world**. That is a great thing in terms of security!

Let’s see how to apply each law to the soul-based architecture of an AI agent.

## The Data Control Law

The first law is about gaining control over data. It states:

*An AI agent must safeguard all data entrusted to it and shall not, through action or inaction, allow this data to be exposed to any unauthorized user.*

Translating this law in terms of the AI agent architecture, we can say that, when acting on behalf of a user, **the probabilistic soul must never access data that the user is not authorized to access**.

To implement this law, make sure your Agent Core has control over any data going to the LLM and to the user/other agents. Make sure that private data remains private. Filter data before sending it to the LLM, the user, or other agents. Apply access control according to your use case.

A typical example of the need for data control is in retrieval algorithms implementation, such as in RAG systems. You specialize your agent’s knowledge with an external source of data, such as a vector database, and want to prevent the user from accessing data they are not authorized to.

**The deterministic soul of the agent has the responsibility to filter the data before passing it to the LLM**. Without this filter, a user asking “summarize my documents” could inadvertently receive documents belonging to other users: a data leak the LLM itself would never catch.

Take a look at the following blog posts to see how to implement the data control law for RAG systems:

* [Building a Secure RAG with Python, LangChain, and OpenFGA](https://auth0.com/blog/building-a-secure-rag-with-python-langchain-and-openfga/)  
* [Secure Java AI Agents: Authorization for RAG Using LangChain4j and Auth0 FGA](https://auth0.com/blog/genai-langchain4j-java-openfga-rag/)  
* [Secure a .NET RAG System with Auth0 FGA](https://auth0.com/blog/secure-dotnet-rag-system-with-auth0-fga/)  
* [Build a Secure RAG Agent Using LlamaIndex and Auth0 FGA on Node.js](https://auth0.com/blog/genai-llamaindex-js-fga/)

## The Command Control Law

The second law focuses on controlling the command flow and making sure that an AI agent does what it is called to do. Nothing more. The law says:

*An AI agent must execute its functions within the narrowest scope of authority necessary. It shall not escalate its own privileges, share secrets, or obey any order that would conflict with the First Law.*

Let’s translate this law in terms of the agent architecture.

If you want to prevent an agent from sharing secrets, do not share secrets with the agent. Or better, **the probabilistic soul (LLM) must never access secrets or tokens**. The deterministic soul can manage tokens, but you must take steps to minimize the likelihood of these falling into the wrong hands. For example, you should use tokens with a short life, but this requires frequent renewals with [refresh tokens](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/). If your agent interacts with multiple third-party services (e.g., Gmail, Slack, Stripe, etc.), do not store long-lived tokens locally for each third-party service. Use a [token vault](https://auth0.com/features/token-vault) instead.

Check out these articles to learn what is the best approach to protect the tokens used by your agent:

* [Build an AI Assistant with LangGraph, Next.js, and Auth0 Connected Accounts](https://auth0.com/blog/ai-assistant-langgraph-nextjs-slack-github/)  
* [Secure Third-Party Tool Calling in LlamaIndex Using Auth0](https://auth0.com/blog/third-party-tool-calling-llamaindex-auth0-python/)  
* [MS Agent Framework and Python: Use the Auth0 Token Vault to Call Third-Party APIs](https://auth0.com/blog/microsoft-agent-framework-python-auth0-token-vault/)

To give your agent only the permissions it needs, use scopes in your access tokens and [apply the principle of least privilege](https://auth0.com/blog/oauth2-access-tokens-and-principle-of-least-privilege/).

But threats to the second law do not just come from token and permission management. These can arise from the input received by the agent: consider prompt injection, which could fool the probabilistic soul of your agent and bypass certain constraints.

The output generated by the LLM can also pose a threat, especially when it is intended to invoke a tool.

In other words, **the deterministic soul is responsible for sanitizing LLM’s input and output**. To learn some techniques for preventing prompt injections and handling improper output, read the following articles:

* [Hiding Prompts in Plain Sight: A New AI Security Risk](https://auth0.com/blog/prompt-injection-ai-browser/#Indirect-Prompt-Injections)  
* [Trusting AI Output? Why Improper Output Handling is the New XSS](https://auth0.com/blog/owasp-llm05-improper-output-handling/)

## The Decision Control Law

The third law is about decision control and says:

*An AI agent must cede final authority for any critical or irreversible decision to its human operator, as long as this deference does not conflict with the First or Second Law.*

In traditional software, the paths between a given input and its output are somehow predetermined. In an agent, you have an unlimited variety of combinations between inputs and outputs, determined almost entirely by the decisions made by the LLM in interpreting the prompt.

In the AI agent architecture, we are delegating to the probabilistic soul the task of interpreting the input and determining what tools to use to achieve a given goal. This gives the agent enormous flexibility and, at the same time, a great responsibility.

To implement the decision control law, you should limit the responsibility of your agent by identifying what are the most critical actions that it can do on your behalf and ask confirmation for executing those actions. **The deterministic soul is responsible for involving the user in critical decisions**.

Depending on the type of agent you are building, these confirmation requests can be interactive or asynchronous. Think of interactive requests like those made by Claude Code or GitHub Copilot when they ask for permission to write to a folder or modify your code. Asynchronous permission requests are those that an unattended agent can send you via email or push notifications.

Whatever your case, engaging the user is crucial to preventing potentially irreparable damage.

Here are a few examples of how you can deal with asynchronous authorization using Auth0:

* [Securing AI Agents: Mitigate Excessive Agency with Zero Trust Security](https://auth0.com/blog/mitigate-excessive-agency-ai-agents/)  
* [Secure “Human in the Loop” Interactions for AI Agents](https://auth0.com/blog/secure-human-in-the-loop-interactions-for-ai-agents/)  
* [Implementing Asynchronous Human-in-the-Loop Authorization in Python with LangGraph and Auth0](https://auth0.com/blog/async-ciba-python-langgraph-auth0/)  
* [Use CIBA Authentication with Auth0 and .NET](https://auth0.com/blog/use-ciba-authentication-with-auth0-dotnet/)

## Your Takeaways for Securing AI Agents

The “two souls” model gives you a concrete mental model for AI agent security. The security insight here is counterintuitive: the component you control least (the LLM) is not where you focus your security effort. **Security must focus on architecting the deterministic soul to constrain the probabilistic one**. This perspective allows you to apply the [Three Laws of AI Security](https://auth0.com/blog/three-laws-ai-security/) by enforcing the Agent Core's responsibility for filtering data, sanitizing inputs/outputs, and managing critical human-in-the-loop decisions.

Here are the main takeaways that I want to highlight:

* **Security is in the code:** You cannot secure the LLM directly; secure the deterministic Agent Core that wraps and controls it.  
* **Constraint is control:** Use the Agent Core to strictly enforce boundaries on the LLM's access to data, secrets, tokens, and external actions.  
* **Human override:** Implement "Human in the Loop" protocols in the deterministic soul for all critical or irreversible decisions.

Implementing all of this from scratch can be challenging and risky. [Auth0 for AI Agents](https://auth0.com/ai) helps you handle the deterministic security layer for you (token management, access control, and human-in-the-loop flows) so you can focus on what your agent actually does.

AI Agents Have Two Souls. You Only Control One.


Learn how to implement the Backend For Frontend (BFF) pattern using Auth0 and ASP.NET Core to eliminate token exposure and enhance SPA security.

Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core

carla_urrea

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

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

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

Staff Developer Advocate

Carla Urrea Stabile

Learn how to mitigate the top five AI agent security risks, including over-privileged tools and memory poisoning, using OWASP 2026 standards and OpenFGA.

Five Critical AI Agent Security Risks and How to Fix Them Before You Ship

Yang Wang headshot

Yang is a Senior Security Engineer in the Okta Identity Defense team. Her role involves a deep focus on identifying and mitigating security risks through incident response, digital forensics, threat detections, security posture analysis, and vulnerability analysis.


Senior Security Engineer

Yang Wang

Matthew-w

Director, Threat Intelligence

Mathew Woodyard

Learn how CheckMate for Auth0 has evolved over six months to provide automated, open-source security audits for your CI/CD pipeline.

Six months ago, we [introduced CheckMate for Auth0](https://auth0.com/blog/introducing-checkmate-for-auth0/), an open-source command-line tool that audits your Auth0 tenant configuration against security best practices. Our vision was simple: give developers and security teams a fast, repeatable way to audit their Auth0 tenant and improve its [security posture](https://auth0.com/blog/level-up-your-security-posture-with-the-auth0-security-detection-catalog/). Since its launch, CheckMate for Auth0 has grown thanks to the support of our community of users. Community members filed bugs, surfaced edge cases and requested features that made CheckMate for Auth0 more powerful. We have been constantly iterating to produce a tool that is more capable, more resilient and ready for production pipelines.

## Six Months of CheckMate for Auth0, by the Numbers

The numbers behind the first six months of CheckMate for Auth0 tell a story of steady growth. We're seeing more users, more contributors, and a maintenance pace that has kept up with both.

- Tool Development  
  - **Consistently increasing `npm` installs** since launch, monthly install volume has grown roughly 4x from October 2025 to March 2026\.  
  - **18 releases** shipped in six months, every one GPG-signed, of course.  
  - **100 pull requests** merged or closed.  
- Impact at a Glance  
  - **628 audits** across 422 unique tenants  
  - **26% repeat** customer rate  
- Growth and momentum  
  - **Steady growth trajectory**: from Oct 2025 to March 2026 peak with 159 runs  
  - Sustained **90 average** tool runs per month  
- Global reach  
  - **47.9% North America, 30.7% APJ, 21.0% Europe**, with emerging footprint in South America and Africa

## CheckMate for Auth0 Is Built with the Community

CheckMate for Auth0 launched with an [issue tracker](https://github.com/auth0/auth0-checkmate/issues), and the community responded by providing feedback, feature requests and bug reports.  External users filed many [issues that were closed](https://github.com/auth0/auth0-checkmate/issues?q=is%3Aissue%20state%3Aclosed%20created%3A%3C2026-04-20), not the core team. As an example of how we improve from community input, when a user [requested](https://github.com/auth0/auth0-checkmate/issues/45) configuration entirely by environment variables, we listened and extended CheckMate for Auth0's functionality.

That community request for environment variable support created a new opportunity for operating CheckMate for Auth0. Before version [`1.6.1`](https://github.com/auth0/auth0-checkmate/releases/tag/v1.6.1), every run required interactive prompts with a person at the keyboard. Useful for periodic audits, sure, but impractical for automation in continuous integration (CI) flows.

With three environment variables set, `AUTH0CHECKMATE_DOMAIN`, `AUTH0CHECKMATE_CLIENT_ID` and `AUTH0CHECKMATE_CLIENT_SECRET`, CheckMate for Auth0 runs completely without user interaction. Additional variables let you control where reports are saved and whether PDF generation is enabled, making it straightforward to slot into any CI environment. Our support for JSON output makes it easy for downstream tools to parse CheckMate for Auth0's findings.

And that changed what the tool could be. It evolved from something you run once during a security review to part of the CI/CD infrastructure your team relies on. But whenever a tool becomes part of your infrastructure, you should trust it to be secure.

## Vigilant Supply Chain Security

[Supply chain compromises](https://auth0.com/blog/defending-against-ai-powered-cli-supply-chain-attacks/) have made headlines repeatedly over the past six months, especially those in CI pipelines. Malicious packages slipping onto npm, typosquatted dependencies that pass code review, legitimate packages quietly compromised between releases.

We [wired automated dependency scanning into the CI pipeline](https://github.com/auth0/auth0-checkmate/commit/23a2a27ac9798ddfa18d3038a1371e1988445981) from the start. When an upstream vulnerability is detected, our CI flow automatically opens a pull request. We routinely review, approve, merge and update our package on `npm` within hours upon discovering potential risks.

## Put It in Your Pipeline and Do Not Miss a Thing

The fastest path to continuous coverage is a scheduled workflow. Create a [dedicated Machine-to-Machine application](https://github.com/auth0/auth0-checkmate?tab=readme-ov-file#-auth0-setup-instructions) in your Auth0 tenant, store its credentials as repository secrets and drop this into your GitHub Actions:

```bash
name: CheckMate for Auth0 Security Audit
on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday at 9am
  workflow_dispatch:

jobs:
  checkmate:
    runs-on: ubuntu-latest
    steps:
      - name: Run CheckMate for Auth0
        env:
          AUTH0CHECKMATE_DOMAIN: ${{ secrets.AUTH0CHECKMATE_DOMAIN }}
          AUTH0CHECKMATE_CLIENT_ID: ${{ secrets.AUTH0CHECKMATE_CLIENT_ID }}
          AUTH0CHECKMATE_CLIENT_SECRET: ${{ secrets.AUTH0CHECKMATE_CLIENT_SECRET }}
          AUTH0CHECKMATE_FILE_PATH: ./reports
        run: npx @auth0/auth0-checkmate

      - name: Upload report
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a  # v7.0.1 at 2026-04-10
        with:
          name: checkmate-report
          path: ./reports
```

It can produce a PDF artifact or nifty JSON output like what’s shown below. Perfect for parsing and automation.

```json
 {  
   "finding_name": "checkGrantTypes",  
   "finding_title": "Application Grant Types",  
   "severity": "High",  
   "name": "single page (rxfKf4sNcbCUbt9SXe4K2xxxxxxx) (First-Party Application)",  
   "field": "unexpected_grant_type_for_app_type",  
   "value": "implicit",  
   "message": "Unexpected grant type \"implicit\" enabled for application \"single page (rxfKf4sNcbCUbt9SXe4K2xxxxxxx) (First-Party Application)\"  with app_type: spa"  
 },  
 {  
   "finding_name": "checkPasswordComplexity",  
   "finding_title": "Databases - Password Complexity",  
   "severity": "Moderate",  
   "name": "ldap",  
   "field": "password_min_length_fail",  
   "value": 8,  
   "message": "The minimum password length configured for ldap is below 12 characters, the minimum length recommended by the US National Institute for Standards and Technology (NIST). The current minimum password length is set to 8"  
 }
```

Every Monday, a fresh audit lands in your GitHub Actions artifacts ready to share with your security-minded organization. When something in your tenant changes, you'll know when the automation runs rather than at the next manual review.

Some of what CheckMate surfaces will be configuration changes you can make today. Others will open conversations about what Auth0 makes possible, like advanced [attack protection](https://auth0.com/docs/secure/attack-protection), [Tenant Access Control Lists](https://auth0.com/docs/secure/tenant-access-control-list), and other capabilities that exist on the platform but may not yet be enabled on your tenant. Either way, you will know exactly where you stand.

Not on Auth0 yet? [Start for free](https://auth0.com/signup) and run your first audit in minutes. Already have an Auth0 tenant? Follow our [the CheckMate readme](https://github.com/auth0/auth0-checkmate/blob/main/README.md) and run your first test. Notice any points for improvement? Do not hesitate to [raise an issue](https://github.com/auth0/auth0-checkmate/issues). We look forward to your participation and the chance to use and improve CheckMate for Auth0 together\!

*These materials and any recommendations within are not legal, privacy, security, compliance, or business advice. These materials are intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments nor all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials. Information regarding Okta's contractual assurances to its customers can be found at okta.com/agreements.* 

CheckMate for Auth0: Six Months of Growth


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

Juan Cruz Martinez

Chris Sevilleja

Chris Sev is the Director of DevRel at Okta. He has been writing code since he was 14. Building businesses, creating written/video content, and loves that we live in the age of the nerd.

He lives in Denver with his wife and 2 kids. When not coding, he does all things outdoors.

Director, Developer Relations

There is no stopping OpenClaw (formerly known as Moltbot and Clawdbot). But here is a five-step checklist to make it safe.

Securing OpenClaw: A Developer's Checklist for AI Agent Security

Bradford Peirce

Product Marketing Manager, Retail

Learn how AI agents are transforming retail and why identity is the foundation of secure AI adoption. Explore Auth0 solutions for AI agent security.

Securing the AI Agents that Power the Future of Retail

Learn how B2B SaaS companies can use Tenancy-as-a-Service to scale past the "Identity Wall" and meet enterprise security requirements like SAML and SCIM.

Breaking the "Identity Wall" with Tenancy-as-a-Service


Hermano-Square-2

Hermano is a Senior Business Value Manager at Okta, helping customers and prospects to articulate the value of Identity and Auth0. He has over 10 years of experience in Management Consulting at Accenture and Amadeus, advising clients in various industries including Aviation, Telecom and Financial Services. Hermano holds a BSc in Business Administration from the University of São Paulo and an MBA from HEC Paris.

Senior Business Value Manager

Hermano Nakata

Optimize your airline's digital strategy with Auth0. Explore how CIAM for airlines and AI agent security enhance loyalty and operational efficiency.

How Identity and Secure AI Deliver Business Value for Airlines

Learn the critical differences between OAuth State, Nonce, and PKCE. Discover how these parameters prevent CSRF, replay attacks, and code interception.

When building secure authentication and authorization flows, the [OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) and [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) (OIDC) specifications are the industry standard. But as developers, we quickly encounter a few cryptic parameters that can be a major source of confusion: `state`, `nonce`, `code_challenge`, and `code_verifier`. The last two are tied to a security mechanism known as [Proof Key for Code Exchange](https://datatracker.ietf.org/doc/html/rfc7636) (PKCE).

All these parameters appear to be random secret strings passed around during the login flow. This leads to common and sometimes dangerous questions: Are they interchangeable? Does PKCE replace the need for `state`? If I'm using `state`, do I still need `nonce`?

The short and emphatic answer is: **No, they are not interchangeable.**

Think of them as three distinct security specialists, each guarding a different door at a different stage of the authentication process. Using one does not and cannot do the job of the others. They work together to create a layered defense that protects your application and your users from a variety of attacks.

To better understand them, let’s analyze them one by one, looking at the specific problem each one was designed to solve.

<AmpContent>
<amp-youtube
    data-videoid="8y76W9FdHjE"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='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/8y76W9FdHjE' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## The State Parameter: Preventing OAuth CSRF

Let's begin with the `state` parameter. It exists to answer a simple question for your application: **"Is this the incoming login response I actually requested?"**.

Its entire purpose is to prevent a class of attacks known as [**Cross-Site Request Forgery (CSRF)**](https://auth0.com/blog/cross-site-request-forgery-csrf/).

### The Attack: Cross-Site Request Forgery (CSRF)

Imagine a user who is logged in to their online bank. In another browser tab, they visit a malicious website. That website might have a hidden link or form that crafts a fake OAuth authorization response and sends it to the callback URL of the user’s online bank, as shown below:

```shell
https://online-bank.com/callback?code=FAKE_CODE_FROM_ATTACKER
```

This is a "forged request." The attacker is *tricking* the user’s browser into sending a request to their bank application that the user *did not initiate*. Without a `state` parameter, your application's callback endpoint might receive this fake code. If the attacker is clever, they could potentially use this vector to trick the bank application into associating the user's session with the *attacker's* account, a "login CSRF" attack.

### The Solution: Add the State Parameter

The `state` parameter solves this by acting as a "claim check." It's an opaque, random, and unguessable string that your application generates **before** the authentication flow even begins.

The flow becomes a secure, verifiable loop. First, your client application generates this unique `state` value. It then *saves* this value, typically in the user's session or a secure short-lived `HttpOnly` cookie. This value is now tied to *this specific user's browser session*.

Next, your application redirects the user to the authorization server's login page and includes the `state` value as a query parameter in the URL. The authorization server knows nothing about this value; its only job is to hold onto it and **echo it back, unmodified**, when it redirects the user back to your application.

When the user returns to your `redirect_uri` (or "callback URL"), the *very first thing* your application must do is compare the `state` value in the incoming request with the `state` value it stored in the user's session.

If they match, this is a legitimate response. Your application can confidently say, "I recognize this. This is the response to the request I sent out just moments ago for *this specific user*". You can now proceed to the next step: exchanging the authorization code.

If they do not match (or if the `state` is missing), this is a red alert. This request is unsolicited. It did not originate from your application, or it's being sent to the wrong user. Your application **must** reject the request immediately, log the attempt, and show an error.

The `state` parameter is your application's way of maintaining context across the HTTP redirects and ensuring the response it's processing is not a forgery.

## The Nonce Parameter: Preventing ID Token Replay

Next, we have `nonce`. This parameter is specific to OpenID Connect (OIDC), which is the authentication layer built on top of OAuth 2.0. If you are *only* using OAuth for *authorization* (getting an access token for an API), you won't use a `nonce`. But if you are using OIDC to *log a user in* and get an [ID token](https://auth0.com/blog/id-token-access-token-what-is-the-difference/), the `nonce` parameter is critical.

The `nonce` (a "number used once") exists to answer a different question: **"Is this ID token I just received *actually* for the login I just initiated?"**.

Its primary job is to prevent **ID token replay attacks**.

### The Attack: ID Token Replay

An ID token is a signed [JSON Web Token (JWT)](https://www.jwt.io/introduction). It's a digital identity card that proves *who* the user is and *when* they authenticated. But what if an attacker somehow intercepts a valid ID token from a previous legitimate login?

The attacker could try to "replay" this token to your application. They could try to trick your application into starting a new login flow and then, at the right moment, substitute their *stolen* (but still validly signed) ID Token. Without a `nonce`, your application might accept this token. It would check the signature, see it's valid, and log the attacker in *as the user from the stolen token*.

### The Solution: Add the Nonce Parameter

The `nonce` parameter solves this attack by cryptographically binding the ID token to the *specific client session that requested it*.

The flow is similar to `state` but has a crucial difference in *where* it's verified. Just like `state`, your client application generates a unique unguessable `nonce` value **before** the redirect and stores it in the user's session. It sends this `nonce` value in the [authorization request](https://auth0.com/blog/anatomy-of-an-oauth2-authorization-request/) alongside the `state`.

The authorization server, upon authenticating the user, takes the `nonce` value you sent and **embeds it as a claim inside the ID token's JWT payload**, as in the following example:

```json
{
  "iis": "https://your-domain.auth0.com",
  "sub": "1234567890",
  "name": "John Doe",
  "nonce": "q-385k-2Pc7",
  "iat": 1516239022,
  "exp": 1516240022
}
```

When your application receives the ID token (typically after exchanging the authorization code), its verification process is now twofold. It must, of course, validate the token's signature. But it *also* must:

1. Decode the ID token.  
2. Extract the nonce claim from inside the token.  
3. Compare this `nonce` claim against the `nonce` value it stored in the user's session.

If they match, the application knows this ID token was *just* minted and was created specifically for *this* login request. If they do not match, this is a replay attack. The token is either old or was intended for a different session. Your application **must** reject it.

This ensures that even a validly signed ID token cannot be reused to impersonate a user in a new login flow.

## PKCE: Securing the Authorization Code

Finally, we come to PKCE. This is a more recent extension to OAuth 2.0, initially meant for [public clients](https://auth0.com/docs/get-started/applications/confidential-and-public-applications), but it is now considered a mandatory best practice for *all* client types.

PKCE answers a question for the *authorization server*: **"Is the client exchanging this authorization code for a token the *same client* that originally requested the code?"**.

It was designed to prevent **authorization code interception attacks**.

### The Attack: Authorization Code Interception

This vulnerability is most dangerous for public clients, like mobile apps and browser-based Single Page Applications (SPAs). These clients cannot securely store a client secret because any code bundled in an app or running in a browser can be reverse-engineered.

In the standard [Authorization Code flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow), the authorization server sends an authorization code back to the client's `redirect_uri`. On a mobile device, this might involve a custom URL scheme (for example, `my-app://callback?code=...`). A malicious app on the same device could register itself to handle the *same* URL scheme, intercept this callback, and *steal the authorization code*.

The attacker, having stolen the code, could send it to the token endpoint. And since the token endpoint for a public client didn't require a client secret, the server had no way to know this *wasn't* the legitimate app. It would happily trade the stolen code for a valid access token, giving the attacker full access to the user's account.

### The Solution: Use PKCE

PKCE prevents this attack by requiring the client to prove it's the same one that started the flow. It's a cryptographic extension that works like a two-part secret handshake.

The flow now involves two new values. First, **before the redirect**, your client application generates a unique, random, high-entropy string called the `code_verifier`. This is the *secret*.

Second, your client transforms the `code_verifier` (usually using a SHA-256 hash and then Base64-URL-encoding it) to create a `code_challenge`. This is the *public* part of the secret.

Your application saves the secret `code_verifier` in its local storage. It then sends the public `code_challenge` (and the hashing method) to the authorization server in the initial authorization request (along with `state` and `nonce`). The authorization server stores this `code_challenge`, associating it with the authorization code it's about to generate.

When the user returns, the client receives the authorization code (which an attacker might still intercept). Now, the crucial step: when the client goes to the `/token` endpoint to exchange the code, it includes the authorization code *and* the original, secret `code_verifier` it had saved.

The authorization server receives this request and performs its check:

1. It takes the `code_verifier` from the request.  
2. It hashes it using the same method the client said it would use.  
3. It compares the result to the `code_challenge` it stored earlier.

If they match, the authorization server knows the client on the other end of this request is the *exact same client* that initiated the flow. It's safe to issue the tokens.

If they do not match, this is an imposter. The attacker only had the code, not the original `code_verifier` secret. The authorization server **must** reject the request.

PKCE effectively creates a dynamic one-time secret for every login flow, protecting the code from theft and misuse, even for clients that live in insecure environments.

<include src="ebook-ads/Oauth2OidcGuide" \>

## Why You Need All Three

It should now be clear that these three parameters are not redundant. They are a perfect example of layered security, protecting different assets at different stages of the process, as the following diagram shows:

![Diagram showing where State, PKCE, and Nonce are verified in the OAuth 2.0 and OIDC authentication flows.](https://images.ctfassets.net/23aumh6u8s0i/2t9QcxUTJSwtMXDRiGRfVz/ee823255803bdce5916f042ba1d296b7/state-nonce-pkce.png)

Following the numbered steps, let's visualize an attacker's very bad day trying to break into a *properly secured* OIDC flow:

1. **CSRF Attack.** The attacker crafts a malicious link with a fake auth code and sends it to a logged-in user.  
   The user's browser sends the request to the client's `redirect_uri`. The client checks for a `state` parameter in the URL, compares it to the one in the user's session, finds it's missing or mismatched, and rejects the request.  
   The `state` parameter protected the **authorization request step**.  
2. **Code Interception Attack.** The attacker is on the user's mobile device and successfully intercepts the *real* authorization code from a legitimate login.  
   The attacker sends the stolen code to the token endpoint. The authorization server, which is expecting a PKCE flow, asks for the `code_verifier`. The attacker doesn't have it.  
   PKCE protected the **code exchange step**.  
3. **Token Replay Attack.** The attacker somehow bypassed all this and got their hands on a *valid ID token* from a previous session. They initiate a new login and try to send this stolen token to the client.  
   The client, which just initiated a *new* login, has a *new* `nonce` stored in its session. It decodes the attacker's stolen ID Token, looks at the `nonce` claim inside, and sees it doesn't match the one in the session.  
   The `nonce` parameter protected the **token issuing/validation step**.

You are not "choosing" between `state`, `nonce`, and PKCE. You are leveraging all three to build a fortress around your authentication flow.

## Comparison Summary

Now you have a clear understanding of `state`, `nonce`, and PKCE. Keep these concepts handy with the following summary table:

![Comparison table summarizing the purpose, attack vector, and verification steps for State, Nonce, and PKCE.](https://images.ctfassets.net/23aumh6u8s0i/6dvoCIgginxQN74zM88ooF/05383b8015d793634ec63e968bce9e56/state-nonce-pkce-table.png)

Demystifying OAuth Security: State vs. Nonce vs. PKCE

auth0_by_okta_hero copy

Auth0 Team

Auth0 for AI Agents is the 2026 Tech Innovation CUBEd Award winner in the Most Innovative AI-Infrastructure Security Solution category.

*TL;DR: Auth0 for AI Agents has been honored with The Tech Innovation CUBEd Award for Most Innovative AI Infrastructure Security Solution. As AI agents increasingly act on behalf of users — calling APIs, accessing documents, performing critical actions — the identity layer becomes a critical attack surface.
*
Auth0 is delighted to announce that [Auth0 for AI Agents](https://auth0.com/ai) has been honored with The Tech Innovation CUBEd Award for the **Most Innovative AI Infrastructure Security Solution**.

The Tech Innovation CUBEd Awards, brought to you by theCUBE and SiliconANGLE, recognizes the world's most innovative companies, visionary leaders, and groundbreaking technologies. The awards honor the contributions of the companies and individuals shaping the future of B2B and B2C technology.

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/2arUfnsEMw0e7lJDzGSvnM/50bfe9366d7c0deaaac979905f33ca70/MostInnovativeAI-InfrastructureSecuritySolution.png" alt="Most Innovative AI-Infrastructure Security Solution," style="width:85%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>

The [Most Innovative AI Infrastructure Security Solution](https://www.thecube.net/awards) award:   
“*Recognizes a security solution specifically designed to protect AI systems, models and infrastructure from emerging threats and vulnerabilities. This award celebrates solutions that address the unique security challenges of AI deployments and ensure the integrity of AI-powered business operations.*”

## Why This Matters

As AI agents increasingly act on behalf of users, calling APIs, accessing documents, performing critical actions, the identity layer becomes a critical attack surface. Most auth solutions weren’t designed for non-human actors operating with delegated permissions across multiple services. That’s the gap we built [Auth0 for AI Agents](https://auth0.com/blog/auth0-for-ai-agents-generally-available/) to fill.

From interactive chatbots to background workers to multi-agent systems, Auth0 for AI Agents gives developers a complete auth solution that covers agent identity, secure token management, human-in-the-loop consent, and fine-grained access control for Retrieval Augmented Generation, all backed by the enterprise-grade auth you already trust.

This recognition underscores our commitment to helping you ship AI agents with built-in auth and security.

Auth0 for AI Agents is the complete auth solution for AI Agents allowing you to:

* Secure your agents, APIs, and users more effortlessly for B2B, B2C, and internal apps. Backed by the enterprise-grade auth you already trust.  
* Implement more secure login experiences so that AI agents — from interactive chatbots to background workers — can identify your users.   
* Retrieve and store API tokens for Google, GitHub, Slack, and more in Token Vault with enhanced security. Auth0 handles access and refresh token management for AI agents, so you don’t have to.  
* Let your AI agents do the work in the background while maintaining oversight and a clear audit trail. Add more secure human-in-the-loop approvals, so that users are only notified to provide consent for critical actions.  
* Set specific parameters for AI agents' access so you can safeguard your users’ data and reduce leaks. With fine-grained access control for Retrieval Augmented Generation, your AI agents can only access authorized data and documents.  
* Secure your MCP servers with Auth for MCP, giving you control over which agents connect, what resources they access, and the actions they perform.

## Build Powerful AI Agents with Auth0

If you’re building agentic systems, this is your reminder that security has to be part of the architecture from day one. 

**Start building today:**

* [Quickstarts](http://auth0.com/ai/docs/get-started)  
* [Docs](http://auth0.com/ai/docs)   
* [How-Tos](https://auth0.com/ai/docs/how-tos)  
* [Sample Apps](https://auth0.com/ai/docs/sample-apps)

**Get started now:** 

* Our free plan includes two connected apps in our Token Vault and more. As you scale, we offer self-service plans with added upgrades. [Start building >>](https://auth0.com/signup?onboard_app=auth_for_aa&ocid=701KZ000000cXXxYAM-aPA4z0000008OZeGAM)  
* Existing Auth0 users can get started for free, regardless of their current Auth0 plan. [Get started>>](https://manage.auth0.com/#/ai-agents)  
* We offer one year of Auth0 free for eligible startups. [Apply today >>](https://auth0.com/startups)  
* We provide eligible nonprofits with 50% off self-service and enterprise plans. [Apply today >>](https://auth0.com/nonprofits)

Auth0 for AI Agents Wins the Most Innovative AI-Infrastructure Security Solution, 2026

Andrew-Riley

As a Product Manager for Identity Security, I’ve spent over a decade, including the last four years at Auth0, navigating the complex landscape of authentication and identity security. I specialize in building products that defend the 'front door' of the digital world, balancing robust protection with a seamless user experience. I believe that security should be an invisible enabler, not a hurdle, evolving constantly to meet new threats while keeping the human journey frictionless. When I’m not fighting bots and securing authentication flows, I spend my free time gaming.

Andrew Riley

Pooja-Bhojwani

Pooja is a Machine Learning Manager at Auth0 with 10 years of experience building and scaling intelligent systems. My background combines a strong foundation in software engineering with eight years of expertise in Data Science, allowing me to bridge the gap between complex research and production-grade machine learning systems. Throughout my career in fintech, e-commerce, and gaming, I have specialized in developing high-impact personalization strategies, robust risk mitigation frameworks, and scalable machine learning solutions. I am passionate about translating advanced machine learning into real-world applications that deliver measurable results while helping keep digital platforms safe and trustworthy.

Manager, Machine Learning

Pooja Bhojwani

Learn how Auth0 is using JA4 fingerprinting to defeat sophisticated bots, bypass TLS spoofing, and improve TLS security for your applications without code changes.

Strengthening Bot Detection with JA4 Signals

Willis-Leung

Willis is currently a Product Marketing Manager Intern for the Okta Secure Identity Commitment, where he contributes to our long-term initiative to lead the industry in the fight against identity-based attacks. Outside of Willis' day job helping elevate Okta's profile and role as a security leader, he enjoys going on evening runs along the Toronto Harbourfront.

Product Marketing Intern

Willis Leung

Linda Gong

Linda Gong is a Staff Product Marketing Manager for Orchestration at Okta, where she leads go-to-market strategy for Okta Workflows and Auth0 Extensibility. With a background in demand generations and marketing analytics, she brings a data-driven mindset to messaging, product launches, and driving adoption. When she’s not crafting product narratives, you’ll likely find her hunting down the best local coffee shops or planning her next travel adventure.

Staff Product Marketing Manager

Help enable real-time SMS alerts across identity lifecycle, from login alerts to security warnings with the Telesign SMS Messaging API.



Telesign SMS Messaging API integration is now available in the Auth0 Marketplace

Antonio Ortells

Antonio is a Senior Product Manager at Okta, where he leads the strategy for the "plumbing" of modern identity: sessions and refresh tokens in Auth0. Drawing on his previous experience as a Solution Architect and Technical Account Manager, Antonio brings a deep, customer-first perspective to building seamless and secure identity solutions. He spends his days obsessing over session protection and developer experience, ensuring that security remains invisible yet robust. When he isn't mitigating session-based risks, you’ll find him cheering at a football stadium or at home baking a newfound cake recipe.

Senior Product Manager

Learn how to use session and refresh token metadata in Auth0 to track device context, manage security flags, and bridge the gap between oblivious and contextual identity management.

A Guide to Auth0 Session and Refresh Token Metadata

Ruby-Ko

Ruby Ko is a Product Marketing Analyst at Okta, where she develops marketing strategies for products that help ISVs achieve enterprise identity readiness. Based in Irvine, California, Ruby started at Okta as an intern and joined full-time after graduating from the University of California, Irvine in 2025.

Product Marketing Analyst

Ruby Ko

Boost SaaS growth by leveraging Auth0 and the Okta Integration Network. Streamline deployments, enhance security, and scale provisioning for enterprise buyers.

Unlock SaaS Growth: Auth0-Powered Apps and the Okta Integration Network

Kunal-Dawar

Kunal Dawar is a Software Engineer at Okta focused on improving the developer experience for Auth0 through SDKs and platform tooling. He is passionate about identity, security, and clean API design, and spends much of his time making complex authentication flows feel simple for developers. Outside of work, he enjoys exploring new ideas, refining his craft in Go, and diving deep into systems architecture.

Software Engineer II

Kunal Dawar

How we rebuilt go-jwt-middleware from the ground up to eliminate the most common JWT pitfalls in Go, add proof-of-possession security, and make the API hard to misuse.

From Runtime Panics to Compile-Time Safety: The go-jwt-middleware v3 Story

Mario-Unkel

My name is Mario Unkel, a Solutions Engineer at Okta and based in the Netherlands. At Okta I focus entirely on helping organizations solve their (Agentic) Identity challenges with Auth0. From startups to the largest Enterprises in the world I love to help get their security leveled-up with the same energy. Before my role at Okta I have worked in various roles from implementation consultant to pre-sales and trainer. In my own spare time I love to travel with my wife and my daughter, work out or watch anything from F1 to Football and the Olympic Games.

Solutions Engineer

Mario Unkel

Explore three B2C use cases where Fine-Grained Authorization (FGA) turns security checkboxes into revenue levers for streaming, gaming, and e-commerce.

The Revenue Potential of Shared Accounts With Fine-Grained Authorization (FGA)


Let's explore why Broken Access Control continues to rank highest on the OWASP list of security risks in web applications and APIs after several years.

Why Broken Access Control Still Dominates the OWASP Top 10 in 2026?

william_johnson

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


Developer Advocate

Will Johnson

The November 2025 Model Context Protocol (MCP) update introduces Client ID Metadata Documents (CIMD) and Cross App Access (XAA). Learn how these changes improve AI agent security.


Model Context Protocol Nov 2025 Specification Update: CIMD, XAA, and Security

Broken Object Level Authorization is the most critical API security vulnerability. Learn how Fine-Grained Authorization (FGA) can help fix it.

According to [OWASP](https://owasp.org/), the worldwide web security community, Broken Object Level Authorization (BOLA) is the most critical vulnerability affecting APIs. What is this vulnerability? How can it be exploited? How can you prevent it in your API? Keep reading to find the answers to these questions.

## What Is OWASP API Security Top Ten?

One of the main goals of the OWASP community is to make developers and technologists aware of the risks their applications and systems are exposed to. With this in mind, the community publishes some documents that highlight what are the most common security risks.

The [OWASP Top Ten](https://owasp.org/www-project-top-ten/) document is the most popular one. It focuses on web development in general. But there is also a more specific document for APIs: the [API Security Top Ten](https://owasp.org/www-project-api-security/).

[Broken Access Control](https://owasp.org/www-community/Broken_Access_Control) is a top risk on the general OWASP Top 10, ranking as the number one most critical vulnerability in both the [2021](https://owasp.org/Top10/2021/) and the [2025](https://owasp.org/Top10/2025/) versions. It is not a single vulnerability, but a category covering several security flaws related to inadequate access control. Several vulnerabilities are related to Broken Access Control, including violation of the principle of least privilege, privilege escalation, metadata manipulation, etc.

The API-specific list focuses on [Broken Object Level Authorization (BOLA)](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/), which has been reported as the most critical risk in both the 2019 and the [2023](https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc.html) versions. It's incredible that after years this authorization failure is still affecting APIs around the world! Is there a way to mitigate if not eliminate this vulnerability?

The answer to this question is positive: you can prevent  this vulnerability from affecting your API by designing a proper authorization system. But before you get to the solution, let's learn what Broken Object Level Authorization is.

## What Is Broken Object Level Authorization?

Authorization is the process of determining what a user has access to. This access control can be done in many different ways based on the business rules of the specific application.

In the API context, each request to a protected endpoint should be analyzed to determine if the client is authorized to access and perform the requested action. Typically, this check is done at the code level and is based on verifying that the client has the right permissions to access the resource (the object) exposed by the API endpoint.

The main problem in this case is to define what is the actual resource to protect.

In some scenarios, it's the API endpoint itself. Consider the `/profile` endpoint: it implicitly returns the profile data of the current user. The API may know who the current user is from the session storage or from the access token sent along with the request.

In other scenarios, the object to protect is the requested resource. Consider the endpoint `profile/42`, which returns the profile data of the user with ID 42. In this case, comparing the current user ID to the requested user ID may not be correct. Think of an administrator who should have access to the profile data of all the users. The authorization check should verify that the current user has permission to access the requested object.

Inaccurate permission checking in endpoints that use object IDs exposes the API to BOLA attacks. In fact, an attacker could manipulate the object ID to gain access to an object for which they have no permissions.

> In the past, the Broken Object Level Authorization (BOLA) vulnerability was called Insecure Direct Object Reference (IDOR). The name was changed because it suggested that the problem was with the ID, while in fact it's with the authorization check.

## An Example of BOLA Vulnerability

To understand how a Broken Object Level Authorization vulnerability can be exploited by an attacker, let's use a practical example.

Suppose your bank provides you with an app to manage your account. Being a curious developer, you take a look at how your app interacts with the server. You notice that it calls the endpoint `https://thebankwebsite.com/accounts/9876543` to get data about your own account whose number is 9876543.

You remember that one of your friends has the same bank as you. You also remember that you made a money transfer to him in the past, so you look for his account number in the messages he has sent you. You find out that his account number is 1029387. So, you take curl or another HTTP client and replay your HTTP request to the bank's server by changing the endpoint's URL: `https://thebankwebsite.com/accounts/1029387`.

Surprisingly, you get the data about your friend's account from the server! This means that the bank's API has a BOLA vulnerability. Their authorization check fails at the object access level.

You can imagine, for example, that the API implementation for that particular endpoint is as follows:

```javascript
const express = require('express');
const app = express();
const { auth, requiredScopes } = require('express-oauth2-jwt-bearer');

//This checks that the provided access token is valid
const validateAccessToken = auth({
  audience: '...yourApiIdentifier...',
  issuerBaseURL: `https://...yourDomain.../`,
});

//This checks that the provided access token grants reading permissions
const checkReadPermissions = requiredScopes('read:account');

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          res.json(getAccountData(req.params.accountNumber));
        }
);
```

This Node.js Express code snippet shows how a GET request on the `/accounts/:accountNumber` endpoint is handled. Note that the endpoint is protected by two middleware:

- `validateAccessToken`, which ensures that the client provides a valid access token.
- `checkReadPermissions`, which ensures that the access token contains the required `read:account` scope in order to allow the client to access the requested account.

Unfortunately, these checks are not sufficient to implement an accurate access to the account object. In fact, they will not prevent you from accessing your friend's account.

<include src="ebook-ads/WebSecurity" />

## How to Prevent BOLA Vulnerabilities

What measures can you take to prevent BOLA vulnerabilities?

A common suggestion is to avoid using easily recognizable object identifiers in your endpoint URL, such as the bank account number in the example above. This measure prevents the knowledge of the object ID from allowing an attacker to compose a specific HTTP request. For example, you could use a GUID in the URL to identify the bank account instead of the bank account number itself. GUIDs are randomly generated values and make them very difficult to guess.

This approach can mitigate the risk of BOLA attacks, but it doesn't solve the problem. If the attacker finds a way to determine the GUID associated with a bank account, this protection will be bypassed.

The real problem is not in the object ID but in the authorization mechanism. The access control of your API should not be limited to controlling access to the endpoint. It should verify that only authorized users can access **the object exposed by the endpoint**.

In the bank account example, this means that additional checks should be performed. For example, you can check that the current user is the owner of the account, as outlined below:

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

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          if (account.userId == userId) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

This would solve the unauthorized access to the bank account described earlier. However, it might not cover other scenarios. For example, consider a bank account with multiple owners. Each owner could have different permissions on the account. Also consider a bank employee: they should be able to access the accounts of their branch customers. And perhaps a regional manager should be able to access the accounts of multiple branches.

As you can see, the authorization policy that your API should implement strictly depends on the specific business logic. This logic is mainly determined by the relationship between users and resources. When this relationship becomes complex, your API code runs the risk of getting messed up.

## What Is Fine-Grained Authorization?

To handle complex authorization policies, you should use Fine-Grained Authorization (FGA). FGA allows you to control access to resources by analyzing a context described by various attributes and relationships. By having access to a detailed context, you can more effectively control who can access what in your system.

You can design and implement FGA in a variety of ways, but the most common models are as follows:

- **Attribute-Based Access Control (ABAC)**. This authorization model allows you to make authorization decisions by evaluating attributes such as the user's role or age, the resource type, size, or status, the action requested, the current date and time, and so on.
- **Policy-Based Access Control (PBAC)**. This [authorization design pattern](https://idpro.org/is-pbac-an-authorization-model/) allows you to make authorization decisions based on policies. It is very similar to ABAC. The main difference is that PBAC focuses more on logic while ABAC relies more on data.
- **Relationship-Based Access Control (ReBAC)**. This authorization model focuses on the relationship between users and resources. This also includes relationships between resources. ReBAC provides a more expressive and powerful authorization model that can describe very complex contexts.

Okta offers [Fine-Grained Authorization](https://fga.dev) through two solutions based on the ReBAC model:

- [Auth0 FGA](https://dashboard.fga.dev/). This is an *authorization service* that centralizes your authorization logic and data. It allows you to define your authorization model, store your authorization data, and make your authorization decisions across all your applications. Read the [Auth0 FGA documentation](https://docs.fga.dev/intro/authorization-and-auth0-fga) to learn more.
- [OpenFGA](https://github.com/openfga). This is the Open Source project powering the Auth0 FGA service. You can install the [OpenFGA Server](https://github.com/openfga/openfga) and use its SDKs to integrate authorization into your applications.

## How FGA Solves Broken Object Level Authorization Vulnerabilities

Auth0 FGA and OpenFGA allow you to fix Broken Object Level Authorization vulnerabilities in your APIs without messing up your code. Whether you use the hosted product or install the Open Source engine on your servers, FGA allows you to centralize the access control to the resources protected by your API.

You can do this in three steps:

1. **Define your authorization model**. In this step, you define the types of objects in your system and their possible relationships with each other. The authorization model is usually fairly static once written. Check out [this document to learn more about defining your authorization model](https://docs.fga.dev/modeling).
2. **Store your authorization data**. This step allows you to define the actual data and its relationships according to the authorization model you defined in the previous step. This represents the state of the system and will be changing as users interact with your application.
3. **Add authorization check to your API**. In the third step, you integrate authorization checks into your API and start leveraging the power of FGA.

### Define your authorization model

Going back to the bank account example, you can define your authorization model in Auth0 FGA by using its [configuration language](https://docs.fga.dev/modeling/configuration-language). The following code shows a minimal example of how your model could be written:

```yaml
model
  schema 1.1
type user
type branch
  relations
    define employee: [user]
type account
  relations
    define branch: [branch]
    define owner: [user]
    define can_create: employee from branch
    define can_view: owner or employee from branch
```

Notice that the last line in the model above defines the account owner and the employees of the branch where the account was opened as the legitimate viewers. This is the basis for avoiding the Broken Object Level Authorization problem.

Using the [Auth0 FGA Playground](https://play.fga.dev/), you can also get a visual representation of this model:

![The bank authorization model in the Auth0 FGA Playground](https://images.ctfassets.net/23aumh6u8s0i/3cklRF8G4IPBGWb07P4JsI/a75e9daf57459430a9c40f620aad7792/auth0-fga-bank-authorization-model.png)

> You can play with the model used in this article by [making your own copy](https://play.fga.dev/stores/create/?id=01GVMW810J23DEBPGT22MFE4M7).

### Store your authorization data

As the next step, you fill this model with actual data. You define your users and add a direct relationship to the objects in your model. You also define relationships between objects and other aspects that depend on your specific model. You provide data to the system using tuples. For example, the following tuples define some relationships related to the bank model presented earlier:

```json
[
  // User Mary is the owner of the account 12345
  {
    "user": "user:mary",
    "relation": "owner",
    "object": "account:12345"
  },
  // User John is an employee of the branch b1
  {
    "user": "user:john",
    "relation": "employee",
    "object": "branch:b1"
  },
  // Account 12345 was created in the branch b1
  {
    "user": "branch:b1",
    "relation": "branch",
    "object": "account:12345"
  }
]
```

To learn how [to populate your authorization model with data, read this document](https://docs.fga.dev/writing-data).

### Add authorization check to your API

Finally, you can add the authorization checks to your API using one of the [available SDKs](https://docs.fga.dev/integration/install-sdk). Referring back to the bank example, the Node.js Express code will perform its authorization checks as follows:

```javascript
const { OpenFgaApi } = require('@openfga/sdk');
const fgaClient = new OpenFgaApi({
  //...configuration...
});

// ...existing code...

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          const { allowed } = await fgaClient.check({
            tuple_key: {
              user: `user:${userId}`,
              relation: 'can_view',
              object: `account:${req.params.accountNumber}`,
            },
          });
  
          if (allowed) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

The authorization check is performed by `fgaClient.check()`, which passes the tuple to be verified to the FGA engine. The FGA engine uses the authorization model and the data you provided to determine if the current user is authorized to view the requested account. Since you have defined there who the legitimate viewers of this account are, your API is not BOLA vulnerable. In addition, your code is kept clean.

Read more about [integrating FGA into your API](https://docs.fga.dev/integration).

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

## Summary

By the end of this article, you should have a clearer idea of what Broken Access Level Authorization is and how Fine-Grained Authorization can help prevent it.

You have begun to explore what BOLA is and how it can be exploited with a practical example. You have seen that the root cause of this vulnerability is an inadequate authorization system. You learned about FGA and saw what Auth0 offers in this area.

Using the API example analyzed earlier, you learned how to integrate it with Auth0 FGA to overcome the BOLA vulnerability in three steps: define an authorization model, populate the model with data, and invoke the authorization check from the API.

In addition to avoiding BOLA vulnerabilities, Auth0 FGA provides a powerful authorization system to solve very complex scenarios effectively and efficiently. [Give it a try](https://fga.dev/).


How Fine Grained Authorization Solves Broken Object Access Level Authorization

Discover why the Model Context Protocol (MCP) deprecated Server-Sent Events (SSE) for Streamable HTTP and how this shift enables stronger authentication, standard CORS policies, and secure session management.

Why MCP’s Move Away from Server-Sent Events Simplifies Security





A new ebook is available to explain why FAPI is essential for regulated industries, and how to move beyond OAuth bearer tokens for top identity security.

FAPI for Developers: Here Is Your Guide


Kailash_pic

Kailash B is a developer at Auth0. He is passionate about simplifying identity and access management for .NET developers, deeply committed to enhancing developer experience within the complex world of IAM.

Senior Software Engineer

Kailash B

Announcing the new Auth0 ASP.NET Core API SDK. Simplify API security with built-in DPoP support, JWT Bearer compatibility, flexible configuration, and zero lock-in.

A New Auth0 ASP.NET SDK to Secure Your API


Dive into the latest Next.js 16 updates for authentication and authorization, and learn how the new defaults improve security for Next.js developers.


Next.js 16: What’s New for Authentication and Authorization


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 Principal Developer Advocate at Okta. He is also an international speaker and a published author.

Deepu K Sasidharan

Discover why standard prompt injection is evolving into a greater threat with AI browsers. Learn about indirect injection risks and how to secure your LLM applications.


Hiding Prompts in Plain Sight: A New AI Security Risk

Discover why Client ID Metadata Documents are replacing Dynamic Client Registration in the Model Context Protocol ecosystem for better security.

Client ID Metadata Documents Are the Future of MCP Client Registration

Maria-v

Maria Vasilevskaya is a leading Identity Defense Security Engineer at Okta. With her extensive experience in identity security, she has held diverse roles including security executive advisory, professional consulting services, identity and security solutions architecture, and solutions engineering. Her primary objective at Okta is to empower customers in maintaining robust security postures by offering expert assistance during critical incidents and providing strategic advice on implementing security practices to prevent future crises.

Principal Security Engineer

Maria Vasilevskaya

A deep-dive guide for developers on essential Auth0 security best practices. Learn to prevent misconfigurations, account fraud, MFA bypass, and token hijacking.

A Comprehensive Guide to Auth0 Security Against Identity Attacks

Prevent configuration drift. Detect changes to critical security defenses like MFA and Attack Protection real-time, leveraging Auth0 Management API logs for enhanced Auth0 security posture.

Proactive Auth0 Security Posture via Real-Time Audit of Management API Logs

What principles guide AI security? We adapt Asimov's Three Laws for modern AI agents to solve core LLM security challenges, from data control to tool access.


The Three Laws of AI Security


Boost your Auth0 security monitoring with eight essential log detections for your SIEM available in the Auth0 Detection Catalog. Protect against credential stuffing, MFA exploits, and authorization request abuse. 

8 Log Detections for Credential Stuffing and MFA Exploit Prevention

carlos-aguilar

Carlos is a Customer Advocate at Auth0, where he helps guide users and developers to find the right solutions for their needs. He has an eight-year professional background in the SaaS and cybersecurity industries, with extensive experience in customer-facing roles such as account management and customer success management. In his free time, he enjoys hiking and actively seeks out opportunities for outdoor activities and sports.

Customer Advocate

Carlos Aguilar

Discover the three key signs that your app is outgrowing its user authentication setup. Learn to solve these challenges and scale with Auth0's advanced features.

Auth0 for Scaling Apps: Advanced Security and Authentication


Learn how to secure your AI agents to prevent Excessive Agency, a top OWASP LLM vulnerability, by implementing a Zero Trust model.

Securing AI Agents: Mitigate Excessive Agency with Zero Trust Security

shiven_ramji

Shiv is an experienced product executive and builder obsessed with creating beautiful products. He is the President of Auth0 at Okta, managing a $1B ARR business and overseeing the company’s product, data, security, and technology strategy and execution. Before Auth0 and Okta, Shiv was the SVP of Product at DigitalOcean, leading DigitalOcean’s products, pricing, and partnerships. Additionally, Shiv has held product leadership positions at global brands, including Amazon, NBCUniversal, LiveIntent, and The Nielsen Company. Shiv was the recipient of the 2023 Top Global CPO Award by the Products That Count community.

Beyond his current corporate focus, Shiv is deeply committed to fostering entrepreneurship and innovation, particularly in Africa. He is an active angel investor and startup advisor and also serves on the boards of [**Products That Count**](https://productsthatcount.com/) and [**Aiven.io**](http://Aiven.io).


President, Auth0

Shiven Ramji

Announcing CheckMate for Auth0, a new, open-source tool to proactively assess and improve your Auth0 security. Analyze your tenant configuration against best practices.

Introducing CheckMate for Auth0: A New Auth0 Security Tool

E017NDYFGQL-U4W9C40NL-51be4d627a6f-512

Ari is a seasoned Product-Led Growth (PLG) leader with a passion for architecting flawless customer journeys. As the VP of Developer-Led Growth at Auth0, he leads the Developer Marketing, Developer Relations, Activation, and Conversion teams, among others. His career journey includes a key role on the Microsoft Developer Evangelism team and a foundational period as a Software Engineer at Southworks and other firms, where he delivered mission-critical projects for Fortune 100 clients.

Vice President, DLG

Ari Schapiro

Explore Auth0's September 2025 product updates, featuring Auth0 for AI Agents, Tenant Access Control List in GA, Dry Run for Auth0 Deploy CLI, and more.




September 2025 in Auth0: Advanced Security Controls and Auth0 for AI Agents

Michelle Agroskin

Michelle Agroskin is a Staff Product Marketing Manager for Okta. She leads the Customer Identity AI, Authorization, and Consumer portfolios; driving go-to-market strategy, messaging, launches, and strategic growth initiatives.

She lives in NYC and in her free time, loves to travel the world and try new restaurants!

Staff Product Marketing Manager, Auth0

Assess your business's AI Agent readiness. Use this checklist to master the unique AI security challenges autonomous agents pose to customer identity and data access.

Is Your Business Ready for AI Agents? The Ultimate AI Security Checklist for Customer Identity

Learn how to improve refresh token security. Explore how to implement advanced token misuse and hijacking detection rules using the Auth0 Detection Catalog.

Refresh Token Security: Detecting Hijacking and Misuse with Auth0

alyssa-hochberg

Strategic Events Manager

Alyssa Hochberg

Oktane Online, the AI security event of the year, streams live Sept 25-26. Get 40+ sessions, keynotes, live announcements, and CPE credits—all for free!

"#security"