DEV Community: Auth0 for Developers

How to Add Auth0 Authentication to Vercel v0 Apps (Step-by-Step)

Auth0 DevRel — Mon, 02 Nov 2026 05:00:00 +0000

Check out this tutorial from Staff Developer Advocate, Michael Liendo on how to build production-ready apps with Auth0 and v0. We launched a new Auth0 integration for v0 that lets builders add real authentication to the applications they build through prompts. Ask v0 to add login, protect a route, support B2B use-cases, connect an enterprise identity provider, or require MFA, and v0 sets up Auth0 instead of generating a placeholder authentication screen.

What You'll Learn:

How to prompt v0 to generate a functional app with the Google Pose SDK
Publishing and testing your v0 app on mobile with custom domain options
Integrating Auth0 into your v0 project for quick, secure authentication
Setting up Google Social Sign-In and database features using natural language prompts

Resources:

The Token That Survived the Patch: An Auth Horror Story 🎃

Jessica Temporal — Fri, 30 Oct 2026 15:00:00 +0000

Pull up a log and get close to the fire 🪵🔥.

In this special Halloween tech horror story, we dissect a real-world developer nightmare: an artifact registry compromised through a chain of small flaws, where a patched vulnerability left an active admin backdoor behind.

The scariest breaches aren't always the ones you miss—they are the ones you believe you already resolved. A software patch closes the hole in your code, but it does not revoke the credentials minted while that hole was open. We break down how silent persistence works in CI/CD dependencies and examine the incident response steps needed to secure your infrastructure after an exploit.

Your Laptop Might Replace Most of Your AI Bill

Carla Urrea Stabile — Wed, 28 Oct 2026 11:58:00 +0000

I've never run an AI model on my own machine, and I assumed the cloud was the best way to get good agentic coding. Then I talked to Deepu K Sasidharan, a Principal Developer Advocate at Auth0 and long-time open source maintainer, who now does most of his coding with a model running on his laptop. He's also the creator of LlamaStash, a Rust tool for running local models.

From skeptic to local-first. Initially, Deepu tried every new model version and wasn't so impressed, until one found bugs in code he had written by hand. That was the moment he stopped resisting and started experimenting.
Local models vs. frontier models. By his own benchmark, a local model on a 128GB laptop lands in the same range as a top cloud model on a complex task, with similar speed apart from a roughly twenty-second wait on the first big prompt.
Why he built his own tool. Ollama felt slow and LM Studio didn't give him enough control, so an initial bash script turned into LlamaStash, a Rust CLI and terminal UI that can run any engine and model combination.
The engineer as architect and manager. He doesn't write most of the code anymore. He plans, sets requirements, and manages a few agents, and he says he doesn't miss the old way.

Things that stuck with me

I asked Deepu to explain llama.cpp like I'd never heard of it. It's the engine that loads the model file into your GPU or RAM and does the computation, and tools like Ollama are wrappers on top of it. His suggestion was to try LlamaStash's init command, or LM Studio if you prefer a GUI.

The part I keep coming back to is how he sets up his harness:

One setup, two harnesses. He uses a different harness for the cloud model and for the local model, and they share the same rules file, plugins, and memory location through symlinks.
Cloud for planning, local for building. An orchestrator skill has the cloud model write the plan and do the final review, while local agents implement it in parallel. A feature that would have cost around $20 on cloud alone now costs about $1, since the local part is just electricity.
Reviews from many angles. Three review rounds can look at a change from twelve angles, including security, correctness, and an adversarial one, which is more than one person skimming a diff would do. If problems remain after three rounds, it stops and tells him, and he says it's usually his own unclear requirement.
Small context on purpose. A huge context window doesn't need to be filled, and the more you fill it, the slower and less accurate the model gets.

Final thoughts

Deepu's setup isn't about picking local over cloud. It's about deciding what runs where, and staying in the seat of the person who sets the requirements and checks the work. Local models make that choice yours, including what happens to your code, your prompts, and your secrets.

Would you give a local model the task of doing most of your coding? Let me know in the comments!

Listen to the full episode

Available on YouTube, Apple Podcasts, and Spotify.

Thanks for reading!

7 Auth0 Free Tier Limits You Must Know Before Building

Auth0 DevRel — Mon, 26 Oct 2026 04:00:00 +0000

Building on Auth0's free tier? While it is a powerful way to get started with identity management, hitting unexpected limits during production can break your system architecture. In this video, we break down the 7 things you must know before designing your auth flow around the Auth0 free plan.

Pricing is subject to change, please use https://auth0.com/pricing as the ultimate source of truth for pricing.

What You'll Learn:

Organizations: Managing the 5-organization cap across environments.
Enterprise Connections: How SAML, OIDC, and directory limits work (plus SAML vs. Social Logins).
Custom Domains: Enabling custom domains on the free plan without paying extra.
Password Hash Migration: Why lazy migration requires a custom database connection.
Fine-Grained Authorization (FGA): How resource-level permissions are billed separately.
Adaptive MFA: Understanding risk-based MFA vs. standard MFA availability.
Tenant Deletion: How to protect side projects and inactive tenants from automated cleanup.

Related Resources:

Tools vs. MCP vs. Skills Explained

Jessica Temporal — Mon, 19 Oct 2026 14:00:00 +0000

We follow Alice, a developer at Acme Corp, to demonstrate how missing any of these layers leads to multi-platform integration headaches and expensive $18,000 security flaws.

🧠 WHAT YOU'LL LEARN:

Why AI tools act as the "hands" that allow models to produce structured intent and call functions
How Model Context Protocol (MCP) acts as the "USB-C for AI," decoupling tools from specific client implementations
How AI Skills provide the "brain" and recipes to enforce business logic, judgment, and guardrails
Security risks across each layer—from prompt injection and tool poisoning to missing human-in-the-loop controls
How to implement OAuth 2.1 authorization and scoping for secure remote MCP servers

🛠️ RESOURCES & LINKS:

If you enjoy this content and want to learn more about identity, security, and access management, subscribe to our channel!

Have a topic you'd like to see covered? Let us know if the comments below 👀

On-Behalf-Of Is a Pattern. Token Exchange Is the Standard.

Andrea Chiarelli — Mon, 19 Oct 2026 08:08:39 +0000

Consider a web API that needs to call a second API, and the second API needs to know whose data it is accessing. The obvious shortcut is to just forward the user's original access token to the downstream service. Do not do this. Relaying a token to a party it was not issued for breaks the trust boundary the token was scoped to in the first place. The middle-tier service needs its own token, one that still carries the user's identity, without reusing the user's actual credential.

This is the problem that On-Behalf-Of (OBO) flows address. But it is worth being precise about what the On-Behalf-Of name actually refers to, because the confusion that follows is not really about competing flows. On-Behalf-Of is an architectural pattern: a label for the shape of this problem, not a protocol for solving it. OAuth 2.0 Token Exchange (RFC 8693) is the IETF-ratified standard eventually built to implement that pattern in an interoperable way. Microsoft's own "OBO" flow is a third thing again: a specific, non-standardized implementation of the pattern that predates the standard and is not compliant with it.

Keep those three apart: the pattern, the standard, and a vendor's implementation. Most of the confusion in this space will then resolve on its own. Including the part where RFC 8693 implementations are named "On-Behalf-Of" and people assume that means they are all doing what Microsoft does.

Let's work through the pattern first, then the one legacy implementation worth understanding on its own terms, then the standard that formalized it, then the part neither one was designed to answer: explicit delegation from the user to the downstream service or agent.

The Problem: A Middle-Tier Service Needs to Act as the User

Three actors show up in every version of this scenario:

a client, which is the application the user is interacting with,
a middle-tier API, i.e., a service that received the user's request and now needs data from somewhere else,
a downstream API: the service that actually holds that data.

The client authenticated once and got a token for the middle-tier API. Now the middle-tier API needs a token for the downstream API, and it needs that token to represent the user, not itself.

This rules out two tempting shortcuts:

Forwarding the client's original token downstream is unsafe, since that token's audience is the middle-tier API, not the downstream one.
Having the middle-tier API call the downstream API with its own service credentials solves the audience problem but creates a worse one: the downstream API can no longer tell whether the actual user is authorized to see this data, because all it sees is the middle tier's own identity.

What is needed is delegation: a new token that identifies the user as the subject of the request, while also recording that the middle-tier API is the one making the call. On-Behalf-Of is the name for exactly that pattern.

OBO as the Pattern Implementation

Microsoft's implementation (the one most developers mean when they say "OBO") is the oldest widely-deployed answer to the problem above, and it's worth understanding on its own terms, since a lot of production systems still run on it. It follows a fixed sequence, as shown in this diagram:

Following the numbered steps:

The client authenticates and requests an access token.
The token endpoint issues Token A, scoped to the middle-tier API.
The client calls the middle-tier API using Token A.
The middle-tier API authenticates itself to the token endpoint and requests a new token for the downstream API.
The token endpoint validates the middle-tier API's own credentials and Token A
The token endpoint issues Token B, scoped to the downstream API.
The middle-tier API calls the downstream API with Token B.
The downstream API responds
The middle-tier API returns the result to the client.

In Microsoft's implementation, a minimal request looks something like this (shared-secret variant):

POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id={middle-tier-api-client-id}
&client_secret={middle-tier-api-client-secret}
&assertion={token-a}
&scope=https://downstream-api.example.com/.default
&requested_token_use=on_behalf_of

Two details matter here:

First, this implementation only works for user principals. If the original token represents an app calling with its own client credentials rather than a signed-in user, there is no user identity to carry forward, and this flow is not the right tool (client credentials chaining is).
Second, Token B should never be relayed back to the client. It was issued for the downstream API's audience, and sending it anywhere else turns a scoped delegation into exactly the kind of token-forwarding problem the pattern exists to prevent.

The most common place this shows up in practice is a chain of calls into Microsoft Graph or another Entra-protected resource: a web app calls its own backend, the backend needs Graph data scoped to the signed-in user, and this flow produces the Graph-scoped token without ever exposing the user's original session token to the backend's downstream dependencies.

A less obvious but genuinely useful variant: this implementation's nonstandard extension for minting SAML assertions, which some SSO integrations still expect instead of an OAuth 2.0 access token. Rather than running a parallel SAML identity provider alongside Entra ID, a service can exchange a user's OAuth token for a SAML assertion scoped to the legacy downstream service. That bridges two protocol generations without forcing a full migration. That is a legacy-protocol bridge specific to this implementation, not something a standardized approach needs to replicate, since most RFC 8693 deployments are already OAuth2-to-OAuth2.

Token Exchange: The Standard That Formalizes the Pattern

OAuth 2.0 Token Exchange is the IETF-ratified, vendor-neutral protocol for the same delegation pattern described above. It defines its own grant type (grant_type=urn:ietf:params:oauth:grant-type:token-exchange). It uses a subject_token to carry the user's identity forward and an optional actor_token to record who is making the call. Unlike Microsoft's implementation, it also specifies an explicit, chainable act claim: each hop in a multi-service call can be nested inside the previous one, so a downstream service can see the full path a request traveled.

We will not go into the details of how Token Exchange works here. For the full tour of Auth0's RFC 8693 implementation, take a look at The Many Faces of OAuth 2.0 Token Exchange and A Developer's Guide to Flexible Token Exchange on Auth0 blog posts, and read the documentation.

The point that matters here is narrower: Token Exchange is nit a rival to On-Behalf-Of. It is what the pattern looks like once someone wrote it down as an interoperable standard.

Who Implements What

The pattern now has two implementations, and which one you can reach for depends on your identity provider: Auth0, Okta, and other identity products implement RFC 8693 directly. Microsoft Entra ID and other products do nit. They still require the older, vendor-specific jwt-bearer grant or use other custom implementations instead.

This is also where the naming confusion actually lives. Several vendors, Auth0 included, have built an RFC 8693 implementation and named it "On-Behalf-Of." Auth0's On-Behalf-Of (OBO) Token Exchange uses grant_type=urn:ietf:params:oauth:grant-type:token-exchange, the actual RFC 8693 grant, nesting the act claim up to five levels deep. That's not a second, competing meaning of "OBO." It is the pattern's name attached to a standardized implementation of it, the same way Microsoft's flow is the pattern's name attached to a non-standardized one. Do nit assume which implementation you are reading about from the name alone. Check the actual grant_type in the vendor's documentation.

The practical decision rule survives all of this naming confusion intact: check what grant type your identity provider actually implements before assuming "On-Behalf-Of" describes one specific wire protocol.

What Is There for AI Agent Delegation?

Both the pattern and its standardized protocol assume a user token already exists to exchange. Neither one has a front-channel step where a user explicitly consents to a named agent acting on their behalf. The exchange happens entirely back-channel, between services that already trust each other, with no moment where the user sees "Agent X wants to act for you" and approves it specifically.

From the downstream service's point of view, the trail has traditionally looked the same whether a human, a cron job, or an autonomous agent made the call. That is starting to change on the audit side: Auth0's Agent as Principal feature (currently Early Access) lets a tenant register a persistent agent identity and surface it in the act claim during token exchange, so a resource server that opts in can tell which specific agent acted, not just which client called. But that is a back-channel improvement to the audit trail, not a front-channel one to consent. Delegation flows still were not designed to let a user approve 'this specific agent' before the fact, and audit trails still cannot tell you whether the agent was authorized to decide to act in the first place, only that it did.

A few individual IETF drafts aim to address this gap. Although none have reached consensus status yet, they are worth tracking:

On-Behalf-Of User Authorization for AI Agents proposes a requested_actor parameter at the authorization request and an actor_token parameter at the token request, so the specific agent's identity gets captured and consented to explicitly. It is front-channel, not back-channel, which is exactly the piece the existing pattern and standard both lack.
OAuth Actor Profile for Delegation standardizes the shape of the act claim across implementations, without dictating authorization policy on top of it. By the way, this is the draft currently adopted by Auth0 for its Agent as Principal feature.
Attenuating Authorization Tokens lets an agent derive a narrower token offline rather than round-tripping to an authorization server for every hop, trading central mediation for independence. That trade-off matters for multi-hop agent chains, i.e., for long chains of agents calling other agents. In this context, RFC 8693's synchronous exchange-per-hop model starts to add real latency.

Every one of these is an individual submission, not a working-group draft, and individual submissions carry no formal standing in the IETF process. Some of them have already expired or are about to expire at the time of writing. This is an area where the standards conversation is active but genuinely unsettled.

However, the IETF's WIMSE working group is now pursuing further standardization in this general space: the Workload Identity in a Multi System Environment (WIMSE) Architecture. It is early there as well, but it is the group to watch if you want to track where this settles.

MCP (Model Context Protocol) illustrates the practical shape of the problem. Map MCP's own actors onto OAuth 2.0 roles and the pattern is familiar: the MCP server is the resource server, the agent runtime is the client, the host application is the OAuth 2.0 client orchestrating the whole thing. But MCP itself treats authorization as optional and defers identity and delegation entirely to whatever external identity provider sits behind it. That mapping clarifies the protocol roles. It does nit tell you which user a given agent is acting for, and that remains the integrator's responsibility to solve, not something the spec hands you.

This is nit a problem unique to agents acting on a user's behalf, either. It rhymes with the confused deputy problem, the decades-old pattern where a privileged service gets tricked into misusing its own authority because it cannot tell a legitimate instruction from an injected one. Granting an agent broad delegated authority without a clear record of who authorized what just gives that old bug a new, more capable host.

What to Actually Do Today

Do not wait for the drafts above to stabilize. Here os what holds up regardless of how that standards conversation resolves:

Reach for the standard, RFC 8693 Token Exchange, wherever your identity provider supports it. Fall back to the vendor-specific jwt-bearer pattern only where the vendor forces it. Check the actual grant type in the docs, not just the feature name.
Log the act claim, or your provider's closest equivalent, on every delegated token, even if your downstream systems cannot natively consume it yet. Record actor, task, and approver at the application layer if the token itself will not carry it. Closing the audit gap in human-to-agent delegation covers concrete ways to do this with correlation IDs and approval checkpoints.
Issue one credential per agent per purpose. Never let an agent hold or relay a human's raw token. If you are building agent-facing infrastructure, a mechanism like Auth0's Token Vault is designed around exactly this constraint: managed, auditable, per-agent tokens for third-party API access. Auth0's Agent as Principal goes a step further by giving each agent its own registered identity with a stable ID, rather than relying on a shared M2M client or service account to stand in for every agent.
Scope every delegated token to the specific task, not the full permission set of whatever credential is doing the calling. A narrower token limits the blast radius if an agent misbehaves or gets tricked into misusing its own authority.
Build the audit trail now, not when the standards settle. Regulatory transparency requirements around automated decision-making are already in effect in a lot of jurisdictions, and historical logs cannot be reconstructed after the fact. Whatever you build today to answer "which agent did this, on whose authority" is worth more than a theoretically cleaner version you build next year.

The Pattern, the Standard, and the Identity Question

Consider the middle-tier API from the opening scenario. The primary question, how to invoke a downstream service using the user's identity without exposing their actual token, has been resolved for years. It began informally through patterns like On-Behalf-Of and is now standardized via RFC 8693 Token Exchange. The specific implementation depends on your identity provider, but the core design strategy is well established.

However, AI agents introduce new complexity. The question is no longer simply whether a service can act on behalf of a user, but whether a specific, designated agent has explicit user consent and an auditable record of that authorization. Neither OBO nor Token Exchange was designed for this capability, and the proposed drafts addressing it have not yet achieved IETF consensus. Until standards emerge, this gap must be managed through detailed logging, fine-grained scoping, and dedicated per-agent credentials.

Introducing The Auth0 Plugin for ChatGPT

Jessica Temporal — Tue, 13 Oct 2026 15:25:34 +0000

The new Auth0 plugin for ChatGPT is here, and it’s a massive productivity win for developers.

In this video, you'll learn how to connect ChatGPT directly to your Auth0 tenant and automatically refactor a standard username/password login into a secure OTP (One-Time Password) flow. Because the plugin leverages your active Auth0 CLI session, you can prompt your way through complex auth changes without ever leaving your editor or digging through documentation.

What You'll Learn

How to install and configure the Auth0 ChatGPT plugin.
Prompting ChatGPT to refactor your codebase for an OTP login flow.
How the plugin uses the Auth0 CLI to manage active tenant sessions securely.

Resources

If you enjoy this content and want to learn more about identity, security, and access management, subscribe to our channel!

Have a topic you'd like to see covered? Let us know if the comments below 👀

Handling Auth in Next.js 16 with Server Actions and Middleware

Aniket Bhattacharyea — Mon, 12 Oct 2026 10:44:27 +0000

TL;DR: Authentication in Next.js has changed significantly — patterns like client-side session hooks and middleware-only authorization can become insecure in a server-first application. Auth0's Next.js SDK v4 aligns with the App Router by replacing legacy route handlers, simplifying session access across server contexts, and supporting route protection.

Authentication in Next.js has changed significantly over the last few major releases. With Next.js 16, the framework fully embraces a server-first architecture: Server Components render on the server by default, Server Actions execute mutations server-side, and the App Router pushes developers toward colocated backend logic rather than traditional API-centric patterns.

That shift changes how authentication should be implemented. Patterns that worked well in older Next.js applications, such as client-side session hooks, /api/auth/* route handlers, and middleware-only authorization checks, can become awkward or even insecure in a server-first application. Session assumptions that were safe in client-heavy architectures no longer hold with Server Actions. Many developers upgrading existing applications discover that older Auth0 integration patterns simply no longer map cleanly to the App Router model.

Instead of working around the framework, the latest Auth0 Next.js SDK is designed specifically for this architecture and integrates directly with the server-first model that Next.js 16 promotes. In this guide, you will learn how to build a production-grade authentication layer in a Next.js 16 App Router application using Auth0’s Next.js SDK v4. This article will cover:

The architectural shift from SDK v3 to v4
How proxy.ts replaces legacy auth route handlers
Session access patterns in Server Components, Server Actions, and API routes
Practical route protection strategies
Security considerations that matter in real-world deployments

What Changed in Auth0 Next.js SDK v4 (and Why It Matters)

Before App Router and Server Components became the default, authentication in Next.js typically revolved around API routes. In the Pages Router era, Auth0 integrations commonly looked like this:

// pages/api/auth/[auth0].ts

import { handleAuth } from '@auth0/nextjs-auth0';

export default handleAuth();

Protected API routes used wrappers like:

withApiAuthRequired()

Session access relied on request/response objects:

getSession(req, res)

This model worked well because applications were heavily request-oriented. Rendering often happened client-side or through getServerSideProps, and API routes formed the natural backend boundary. Next.js 16 changes the execution model entirely. Server Components run directly on the server without explicit request handlers. Server Actions execute independently from page renders, and route segments can stream progressively. The framework assumes that most logic lives server-side from the beginning.

The diagram below shows how Auth0 SDK v4 aligns directly with that architecture, tracing a request from initial HTTP call through to protected mutation.

Instead of manually defining /api/auth/[auth0], the SDK now auto-mounts authentication routes like /auth/login, /auth/logout, /auth/profile, etc. when you include a properly configured proxy.ts file (more on this file in the next section).

The SDK also simplifies configuration substantially. For example, you can create a shared Auth0 client with only one line of code:

// src/lib/auth0.ts

import { Auth0Client } from '@auth0/nextjs-auth0/server';

export const auth0 = new Auth0Client();

The SDK automatically reads environment variables like AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_CLIENT_SECRET, AUTH0_SECRET, APP_BASE_URL

This minimal, boilerplate-free setup is intentional. The SDK naturally integrates into the Next.js server-first runtime rather than requiring extensive bootstrapping code.

The biggest practical change is session access. Instead of:

getSession(req, res)

you now use:

await auth0.getSession()

with no request or response arguments.

That works because the SDK reads encrypted session cookies directly from the current server execution context.

The proxy.ts Pattern

The most important architectural concept in Auth0 SDK v4 is proxy.ts.

In Next.js 16, proxy.ts acts as a request interceptor that executes before the framework processes a route. It replaces the former middleware.ts convention, with the new name emphasizing that this code runs at the network boundary and can rewrite, redirect, or modify requests and responses before they reach your application routes. For Auth0, this interception point allows the SDK to handle authentication routes and session-related processing before the request continues into the application.

Here is the standard implementation:

// src/proxy.ts

import type { NextRequest } from 'next/server';
import { auth0 } from './lib/auth0';

export async function proxy(request: NextRequest) {
  return await auth0.middleware(request);
}

export const config = {
  matcher: [
    /*
     * Match all request paths except:
     * - _next/static
     * - _next/image
     * - favicon.ico
     * - sitemap.xml
     * - robots.txt
     */
    '/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)',
  ],
};

This file is the mechanism that enables the SDK to intercept and handle authentication routes automatically. Without it, requests to /auth/login or /auth/callback will typically return 404 errors.

Note: If your application uses a src/ directory, the proxy.ts file must live inside this src directory. Otherwise, it belongs at the project root. Misplacing the file often causes silent failures where auth routes return 404s even though the SDK appears configured correctly.

Understanding the matcher pattern

The matcher pattern is more important than it initially appears.

This line tells Next.js which requests should pass through the Auth0 proxy layer:

'/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)'

The exclusions affect both performance and security. For example, paths like _next/image serve optimized image requests, which should not be intercepted as this can introduce unnecessary auth processing overhead and break asset delivery. On the other hand, paths like favicon.ico and robots.txt are public assets that should not be protected behind authentication. You must also set up the matcher to exclude any other public routes in your app, but be careful not to accidentally exclude sensitive paths, as this may cause them to bypass auth interception entirely. This is why you should treat matcher configuration as part of your security model, not merely routing boilerplate.

Auto-mounted routes

Once proxy.ts is configured, the SDK automatically mounts several auth endpoints:

/auth/login
/auth/logout
/auth/callback
/auth/profile
/auth/access-token
and others

These routes are now part of the SDK contract, and you no longer need to manually implement them yourself.

Session Access in the Server with Components, Actions, and API Routes

One of the most important concepts in Next.js 16 authentication is understanding that each server execution context behaves differently. Server Components, Server Actions, and API routes all run on the server, but session access patterns are not identical across them.

Server Components

Server Components are the cleanest place to access session state. Because they execute directly on the server, they can read encrypted session cookies without any client-side round trip.

Here is an example:

// app/dashboard/page.tsx

import { redirect } from 'next/navigation';
import { auth0 } from '@/lib/auth0';

export default async function DashboardPage() {
  const session = await auth0.getSession();

  if (!session) {
    redirect('/auth/login');
  }

  return (
    <main>
      <h1>Welcome, {session.user.name}</h1>
    </main>
  );
}

getSession() reads directly from encrypted cookies. If no session is found, the user is redirected. No API request is required, and no token exchange happens during rendering. The redirect occurs server-side before protected content renders. This is both simpler and more secure than relying on client-side auth checks after hydration.

Server Actions

Server Actions are where many developers accidentally introduce security gaps. Even though Server Actions execute on the server, they are invoked independently from the client. That means they cannot assume the session state from a previous page render is still valid, and every Server Action must re-validate authentication explicitly.

For example:

// app/actions/update-profile.ts

'use server';

import { auth0 } from '@/lib/auth0';

export async function updateProfile(data: FormData) {
  const session = await auth0.getSession();

  if (!session) {
    throw new Error('Unauthorized');
  }

  const userId = session.user.sub;

  // Protected mutation logic
  await saveUserProfile(userId, data);
}

Some developers see this repeated session validation as redundant, but it is not. Server Actions are independent execution contexts. A user may have logged out, had their session invalidated, or switched accounts between the initial render and the action invocation. That is why you should treat every Server Action as a fresh authenticated request in order to avoid critical authorization bugs.

API routes

For API routes, the SDK still provides a convenient protection wrapper:

// app/api/admin/route.ts

import { auth0 } from '@/lib/auth0';

export const GET = auth0.withApiAuthRequired(async function GET() {
  return Response.json({
    success: true,
  });
});

This is often the most straightforward approach for protected APIs because unauthenticated requests automatically receive a 401 Unauthorized response.

Accessing User Data and Tokens

Once you have a session, you can access user information directly:

const session = await auth0.getSession();

const user = session?.user;

If you need to call a third-party API on behalf of the user, you can also retrieve the access token:

const token = await auth0.getAccessToken();

Route Protection Strategies

There is no single “correct” protection strategy in Next.js 16. The right approach depends on how much of your application is private and how centralized you want authorization logic to be.

Page-level protection

The most explicit strategy is protecting individual pages:

const session = await auth0.getSession();

if (!session) {
  redirect('/auth/login');
}

This approach gives maximum control and clarity since you can tweak the authorization logic for each page.

Protecting individual pages works especially well when:

Only some routes are protected
Authorization rules vary per page
You need custom redirect logic

The downside is repetition at scale. Having this guard for every page can get too verbose.

Layout-level protection

For larger applications, layout-level protection is usually more maintainable.

For example, this specifies that everything nested under /dashboard now requires authentication automatically:

// app/dashboard/layout.tsx

import { redirect } from 'next/navigation';
import { auth0 } from '@/lib/auth0';

export default async function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const session = await auth0.getSession();

  if (!session) {
    redirect('/auth/login');
  }

  return <>{children}</>;
}

This is often the best tradeoff for applications with clearly separated public and private route segments, such as a CMS with a public homepage and a dashboard for authenticated users.

proxy.ts-level protection

For applications where nearly every route requires authentication, protection can move even higher into the request pipeline. You can extend the proxy matcher to blanket-protect large portions of the app. This reduces duplication and centralizes enforcement. However, it is usually less flexible than page or layout-level checks for applications that mix public marketing pages with authenticated dashboards.

Using useUser()

So far, you have seen how we can authenticate the user on the server. But what about user profile access on the client-side? The SDK also provides a client-side hook:

useUser()

useUser() is useful for authentication and authorization in the UI, such as conditional UI rendering, user avatars, client-side personalization, navigation states, etc., but it should not be trusted for authorization decisions. Client-side state can be stale, manipulated, or temporarily inconsistent. For anything involving data access, mutations, permissions, or protected rendering, you should always validate using getSession() on the server.

Security Considerations

The following are some of the most common security tips that you should keep in mind when using Auth0 with Next.js Server Actions and Middleware.

AUTH0_SECRET rotation

The AUTH0_SECRET environment variable encrypts session cookies. If it changes, existing cookies can no longer be decrypted, resulting in errors like JWEDecryptionFailed.

In practice, users may need to clear cookies or re-authenticate after secret rotation. This becomes particularly important in CI/CD environments where secrets may accidentally differ across deployments.

Allowed callback, logout, and origin URLs

These Auth0 dashboard settings are security controls, not just configuration details.

Examples include:

Allowed Callback URLs
Allowed Logout URLs
Allowed Web Origins

These settings protect against malicious redirect flows and unauthorized origins. If they do not match your deployed application URLs exactly, authentication flows will fail intentionally.

Do not trust client-side session state

Authorization decisions should always happen server-side. This principle deserves repeating:

useUser() is for UI
getSession() is for authorization in the server

Relying on the client state for protected actions is one of the easiest ways to introduce privilege escalation bugs into Next.js applications.

Protect environment variables

Secrets like AUTH0_CLIENT_SECRET must never be exposed to the client bundle. Fortunately, Next.js only exposes variables prefixed with NEXT_PUBLIC_ to client-side code. None of the Auth0 secrets use that prefix, so they are safe from being exposed by Next.js.

However, they can still be accidentally made public. To prevent that, always store them in a .env file, and never check it into version control.

Rethinking Auth in the Server Actions Era

Authentication in Next.js 16 requires a different mindset than earlier generations of the framework. The App Router, Server Components, and Server Actions fundamentally change where code executes and how you trust boundaries should be enforced.

In this guide, you learned how Auth0’s Next.js SDK v4 aligns with that architecture by replacing legacy route handlers with the proxy.ts interception model, simplifying session access through server-native APIs, and supporting protection strategies that scale from individual pages to entire application segments. You also saw why session validation must happen independently across Server Components, Server Actions, and API routes, and why server-side authorization remains essential even in highly interactive React applications.

Auth0 is the identity platform behind all of this: developer-first, deeply flexible, and designed to scale from a weekend project to enterprise-grade infrastructure without forcing teams to trade control for convenience.

The Next.js SDK v4 is a strong example of that philosophy in practice. Instead of layering abstractions on top of the framework, it embraces the Next.js server-first architecture directly through patterns like proxy.ts, server-native session access, and streamlined configuration. The result is an authentication model that feels natural inside modern Next.js applications while still supporting the advanced authorization, multi-tenant identity, and extensibility requirements that growing applications eventually need.

Type-Safe Authentication in Rust with Auth0 and Axum

Aniket Bhattacharyea — Mon, 12 Oct 2026 10:36:40 +0000

CLI tools are deeply embedded in modern developer workflows. But while browser-based authentication is naturally integrated into web applications, and desktop and mobile applications work well with it, CLI applications present a unique challenge: there is no available browser or redirect URL to complete a standard OAuth login flow.

This is exactly the problem the OAuth 2.0 Device Authorization Flow was designed to solve. Rather than redirecting users within the application, the CLI requests a temporary device code, displays a short verification URL and user code, and waits while the user authenticates in their browser. Once complete, the CLI receives tokens it can use for authenticated operations. You have likely encountered this flow before without realizing it. Smart TVs, IoT devices, and headless servers all rely on it when launching or redirecting to a browser is inconvenient or impossible.

In this tutorial, you will build a complete end-to-end system in Rust and Axum using Auth0. First, you will create a Rust CLI that authenticates users using the Auth0’s Device Authorization Flow and retrieves both an ID token and an access token. Then, you will build an Axum API to validate that access token before allowing access to a protected route. Together, these two pieces demonstrate the full authentication and authorization lifecycle: one application obtains trust, and another verifies it.

Prerequisites

To follow along with this tutorial, you will need:

An Auth0 account. You can sign up for free.
The Rust toolchain installed on your system.

Configure Auth0

Start by creating a new Native Application in the Auth0 dashboard.

Open the Auth0 Dashboard, navigate to Applications > Applications, and click Create Application. Select Native and give the application a name like Rust CLI Demo, as you can see in the following screenshot.

Native applications are designed specifically for desktop applications and CLI tools that cannot securely store a client secret.

Once the application is created, open the Settings tab, scroll to Advanced Settings > Grant Types, and enable Device Code as illustrated in the screenshot below.

This step is critical because Auth0 disables the Device Authorization grant by default. If you skip it, the token polling request will fail with an unauthorized_client error that is difficult to diagnose if you do not already know the grant type is disabled.

Now, save your changes.

You will also need to copy the Domain and Client ID values from the Settings page. Store these somewhere safe, as you will need them later.

Next, you will create an API in Auth0. This represents the secure API that you will access. Navigate to Applications > APIs, click Create API, give it a name, and set an identifier such as https://rust-api-demo.example.com, as shown in the following screenshot.

This API identifier becomes the audience for your access tokens.

Now, you need to give your application access to the API. Go to Application Access and click Edit next to the name of your application. In the User-Delegated Access tab, click Grant Access. Your screen should look like the screenshot below.

Create a CLI in Rust

With Auth0 configured, you can now start writing the Rust code. The first thing you need to create is a Rust CLI that uses the Device Authorization Flow to authenticate with Auth0.

Create a new Rust workspace:

mkdir rust-auth0-demo
cd rust-auth0-demo

cargo new auth-lib --lib
cargo new auth0-cli
cargo new auth0-api

These commands create a rust-auth0-demo directory and three Rust projects within it.

Configure the workspace root Cargo.toml:

[workspace]
resolver = "2"

members = [
    "auth-lib",
    "auth0-cli",
    "auth0-api"
]

Build the Shared Authentication Library

The token verification logic lives in the shared auth-lib library crate used by both the CLI and API.

Inside auth-lib/Cargo.toml, add the following dependencies:

[dependencies]
anyhow = "1.0.102"
jsonwebtoken = { version = "10.4.0", features = ["rust_crypto"] }
reqwest = { version = "0.13.4", features = ["form", "json"] }
serde = { version = "1.0.228", features = ["derive"] }
serde_json = "1.0.150"

These dependencies each serve particular functions:

anyhow: Simplifies error handling and propagation across the application.
jsonwebtoken: Validates and decodes JWTs using Rust-based cryptographic verification.
reqwest: Sends HTTP requests to Auth0 APIs with form and JSON support.
serde: Serializes and deserializes Rust structs to and from JSON.
serde_json: Provides JSON parsing, generation, and the json! macro for structured responses.

Create the following structure in the auth-lib directory:

auth-lib/
├── src/
│   ├── lib.rs
│   ├── auth.rs
│   └── models.rs

Define typed models

Inside auth-lib/src/models.rs, define the data models, which eliminate entire categories of bugs:

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
pub struct DeviceCodeResponse {
    pub device_code: String,
    pub user_code: String,
    pub verification_uri: String,
    pub verification_uri_complete: String,
    pub expires_in: u64,
    pub interval: u64,
}

#[derive(Debug, Deserialize)]
pub struct TokenResponse {
    pub access_token: String,
    pub id_token: String,
    pub expires_in: u64,
    pub token_type: String,
}

#[derive(Debug, Deserialize)]
pub struct TokenError {
    pub error: String,
    pub error_description: Option<String>,
}

#[derive(Debug, Serialize, Deserialize)]
#[serde(untagged)]
pub enum Audience {
    Single(String),
    Multiple(Vec<String>),
}

#[derive(Debug, Serialize, Deserialize)]
pub struct UserClaims {
    pub sub: String,
    pub name: Option<String>,
    pub email: Option<String>,
    pub iss: String,
    pub aud: Audience,
    pub exp: usize,
}

#[derive(Debug, Deserialize)]
pub struct Jwk {
    pub kid: String,
    pub n: String,
    pub e: String,
}

#[derive(Debug, Deserialize)]
pub struct Jwks {
    pub keys: Vec<Jwk>,
}

Without these typed structs, authentication code often becomes fragile JSON parsing logic with unchecked assumptions about response fields. Here, every expected field is explicit and validated during deserialization.

Implement JWT Validation

Inside auth-lib/src/auth.rs, add the logic that verifies the JWT:

use anyhow::Result;
use jsonwebtoken::{
    decode,
    decode_header,
    Algorithm,
    DecodingKey,
    Validation,
};
use reqwest::Client;

use crate::models::{Jwks, UserClaims};

const DOMAIN: &str = "YOUR_DOMAIN";

pub async fn validate_token(
    token: &str,
    audience: &str,
) -> Result<UserClaims> {

    // Decode JWT header
    let header = decode_header(token)?;

    let kid = header
        .kid
        .ok_or_else(|| anyhow::anyhow!("Missing kid"))?;

    // Fetch JWKS
    let client = Client::new();

    let jwks: Jwks = client
        .get(format!(
            "https://{}/.well-known/jwks.json",
            DOMAIN
        ))
        .send()
        .await?
        .json()
        .await?;

    // Find matching key
    let jwk = jwks
        .keys
        .into_iter()
        .find(|k| k.kid == kid)
        .ok_or_else(|| anyhow::anyhow!("No matching JWK"))?;

    // Build RSA decoding key
    let decoding_key = DecodingKey::from_rsa_components(
        &jwk.n,
        &jwk.e,
    )?;

    // Configure validation
    let mut validation =
        Validation::new(Algorithm::RS256);

    validation.set_audience(&[audience]);

    validation.set_issuer(&[
        &format!("https://{}/", DOMAIN)
    ]);

    // Decode and validate
    let token_data = decode::<UserClaims>(
        token,
        &decoding_key,
        &validation,
    )?;

    Ok(token_data.claims)
}

The validate_token function verifies that a JWT was genuinely issued by Auth0 and has not been tampered with. It fetches Auth0’s public signing keys (JWKS), selects the correct key using the token’s kid, validates the token signature and claims such as issuer and audience, and finally deserializes the payload into a strongly typed UserClaims struct.

Here, you can again see Rust’s strong typing in action. The deserialization into the UserClaims struct guarantees the presence of all the required fields. If any field is absent, you get a hard error instead of silently failing parsing.

Finally, export the modules in auth-lib/src/lib.rs:

pub mod auth;
pub mod models;

Build the CLI and Device Authorization Flow

To start building the CLI and device authorization flow, first, move into the CLI project:

cd auth0-cli

Add the following dependencies in Cargo.toml:

[dependencies]
anyhow = "1.0.102"
jsonwebtoken = { version = "10.4.0", features = ["rust_crypto"] }
reqwest = { version = "0.13.4", features = ["form", "json"] }
serde = { version = "1.0.228", features = ["derive"] }
serde_json = "1.0.150"
tokio = { version = "1.52.3", features = ["full"] }
auth-lib = { path = "../auth-lib" }

Request the device code

Before you can add a function to request the device code, which is the first step in the authorization flow, you need to add the following imports and variables inside auth0-cli/src/main.rs:

use anyhow::Result;

use auth_lib::{
    auth::validate_token,
    models::{
        DeviceCodeResponse,
        TokenError,
        TokenResponse,
    },
};

const DOMAIN: &str = "YOUR_DOMAIN";
const CLIENT_ID: &str = "YOUR_CLIENT_ID";
const AUDIENCE: &str = "YOUR_AUDIENCE";

Note: This code hardcodes the domain, client ID, and audience values for simplicity. These values are not sensitive and can be safely stored in code. For more flexibility or to store sensitive secrets, you can use a crate like dotenv to store values as environment variables.

Make sure you replace the placeholder values with the data from Auth0.

Add the request_device_code() function in main.rs to request the device code and start the Device Authorization Flow:

async fn request_device_code() -> Result<DeviceCodeResponse> {

    let client = reqwest::Client::new();

    let response = client
        .post(format!(
            "https://{}/oauth/device/code",
            DOMAIN
        ))
        .form(&[
            ("client_id", CLIENT_ID),
            ("scope", "openid profile email"),
            ("audience", AUDIENCE),
        ])
        .send()
        .await?;

    let device_code = response
        .json::<DeviceCodeResponse>()
        .await?;

    Ok(device_code)
}

This endpoint makes a request to /oauth/device/code in your Auth0 domain with the client ID, scope, and audience data. Auth0 returns a short-lived device code along with instructions for the user.

Poll for the token

Once the code is retrieved, the next step is to show the user the code and the login URL. Since a CLI has no redirect URL or callback mechanism, the only way to know when the authorization is finished is to poll for the status in regular intervals.

Add the following code in main.rs:

async fn poll_for_token(
    device_code: &str,
    interval: u64,
) -> Result<TokenResponse> {

    let client = reqwest::Client::new();
    let mut interval = interval;

    loop {

        let response = client
            .post(format!(
                "https://{}/oauth/token",
                DOMAIN
            ))
            .form(&[
                (
                    "grant_type",
                    "urn:ietf:params:oauth:grant-type:device_code"
                ),
                ("device_code", device_code),
                ("client_id", CLIENT_ID),
            ])
            .send()
            .await?;

        if response.status().is_success() {
            return Ok(
                response
                    .json::<TokenResponse>()
                    .await?
            );
        }

        let error = response
            .json::<TokenError>()
            .await?;

        match error.error.as_str() {

            "authorization_pending" => {
                println!("Waiting for authentication...");
            }

            "slow_down" => {
                println!("Slowing polling interval...");
                interval += 5;
            }

            "expired_token" => {
                anyhow::bail!("Device code expired");
            }

            "access_denied" => {
                anyhow::bail!("User denied access");
            }

            other => {
                anyhow::bail!(
                    "Unhandled error: {}",
                    other
                );
            }
        }

        tokio::time::sleep(
            tokio::time::Duration::from_secs(interval)
        )
        .await;
    }
}

The poll_for_token function repeatedly checks Auth0’s token endpoint to see whether the user has completed authentication in the browser. This function:

Sends the device code obtained earlier
Handles all possible OAuth device authorization flow responses such as authorization_pending, slow_down, and access_denied,
Waits between polling attempts using Tokio’s async sleep
Returns the access and ID tokens once authentication succeeds.

Once again, the strong typing ensures that the JSON has all the required fields.

OAuth device authorization flow responses are inherently asynchronous, and Rust forces you to consciously handle every possible outcome using the match statement instead of silently ignoring error states.

Wire the two functions

Finally, wire these two functions together in the main function:

#[tokio::main]
async fn main() -> Result<()> {

    let device =
        request_device_code().await?;

    println!(
        "Visit:\n{}",
        device.verification_uri_complete
    );

    println!(
        "Code: {}",
        device.user_code
    );

    let token = poll_for_token(
        &device.device_code,
        device.interval,
    )
    .await?;

    println!("Access Token: {}", token.access_token);

    Ok(())
}

The main function calls the request_device_code function, prints the verification URL and the device code, and calls the poll_for_token function. The access token returned from this function is printed.

You can run the CLI by executing cargo run. You should see an output like this:

Visit:
https://your-tenant.auth0.com/activate?user_code=ABCD-EFGH
Code: ABCD-EFGH
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...

Once you visit the URL in your browser, you will be prompted to log in with Auth0. You can use an existing Auth0 account to log in or create a new account. Once you log in, Auth0 generates a token, which your code will automatically fetch. You will see the access token printed in the terminal:

Access Token: eyJhbGciOiJSUzI1NiIsIn....

Note that this example prints the access token for demo purposes only. In a real-world application, you should never log the access token.

Fetch the Authenticated User

The token returned from the poll_for_token function also includes an ID token, which contains information about the user's identity. The CLI can validate the ID token and extract information about the user, like name or email.

Add the following function in the same file:

fn say_hi(claims: &auth_lib::models::UserClaims) {

    let name = claims
        .name
        .as_deref()
        .unwrap_or("user");

    println!("Welcome, {}!", name);
}

This function extracts the name field from a UserClaims object and prints a greeting.

You can also fetch the user info from the /userinfo endpoint by passing the access token.

Change the main function to call the validate_token function and pass the returned claims to say_hi:

#[tokio::main]
async fn main() -> Result<()> {

    let device =
        request_device_code().await?;

    println!(
        "Visit:\n{}",
        device.verification_uri_complete
    );

    println!(
        "Code: {}",
        device.user_code
    );

    let token = poll_for_token(
        &device.device_code,
        device.interval,
    )
    .await?;

    let claims = validate_token(
        &token.id_token,
        CLIENT_ID,
    )
    .await?;

    say_hi(&claims);

    println!(
        "Access token:\n{}",
        token.access_token
    );

    Ok(())
}

Now, when you run it, you will see the user's name being printed:

Visit:
https://your-tenant.auth0.com/activate?user_code=ABCD-EFGH
Code: ABCD-EFGH
Waiting for authentication...
Waiting for authentication...

Welcome, Alice!

Access token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

At this stage, you have a fully authenticated CLI application using Auth0’s Device Authorization Flow.

Protect an Axum API Route with Auth0

Now that the CLI can retrieve an access token, the next step is building a protected API accessible through it.

Move into the API project:

cd ../auth0-api

Add dependencies to Cargo.toml:

[dependencies]
auth-lib = { path = "../auth-lib" }

axum = "0.8"
tokio = { version = "1", features = ["full"] }
serde_json = "1"

Axum is a modern asynchronous web framework for Rust built on top of Tokio and Hyper. With its simple and modular design, Axum makes it easy to route requests to handlers with a macro-free API and generate responses with minimal boilerplate. This tutorial uses Axum to create a protected API route that validates Auth0 access tokens before allowing access to authenticated users.

Create a JWT extractor

The first step in protecting your API route is creating a JWT extractor middleware that reads the Authorization header, extracts the Bearer token, validates the JWT, and rejects invalid tokens with 401 Unauthorized.

Inside auth0-api/src/main.rs, add the following code:

use axum::{
    extract::FromRequestParts,
    http::{request::Parts, StatusCode},
    routing::get,
    Json,
    Router,
};

use serde_json::json;

use auth_lib::{
    auth::validate_token,
    models::UserClaims,
};

const AUDIENCE: &str = "YOUR_AUDIENCE";

pub struct AuthUser(pub UserClaims);

impl<S> FromRequestParts<S> for AuthUser
where
    S: Send + Sync,
{
    type Rejection = (
        StatusCode,
        Json<serde_json::Value>,
    );

    async fn from_request_parts(
        parts: &mut Parts,
        _state: &S,
    ) -> Result<Self, Self::Rejection> {

        let auth_header = parts
            .headers
            .get("Authorization")
            .and_then(|v| v.to_str().ok())
            .ok_or((
                StatusCode::UNAUTHORIZED,
                Json(json!({
                    "error":
                    "Missing authorization header"
                })),
            ))?;

        let token = auth_header
            .strip_prefix("Bearer ")
            .ok_or((
                StatusCode::UNAUTHORIZED,
                Json(json!({
                    "error":
                    "Invalid bearer token"
                })),
            ))?;

        let claims = validate_token(
            token,
            AUDIENCE,
        )
        .await
        .map_err(|err| (
            StatusCode::UNAUTHORIZED,
            Json(json!({
                "error": "Invalid token",
                "details": err.to_string(),
            })),
        ))?;

        Ok(AuthUser(claims))
    }
}

This middleware centralizes authentication logic so that protected routes only execute if validation succeeds.

Create the protected route

The API validates the access token. If the token is valid, a message is shown:

async fn protected(
    AuthUser(claims): AuthUser,
) -> Json<serde_json::Value> {

    Json(json!({
        "message":
            "You are seeing a protected route",

        "subject": claims.sub,
    }))
}

Create the main function to set up the router:

#[tokio::main]
async fn main() {

    let app = Router::new()
        .route("/protected", get(protected));

    let listener = tokio::net::TcpListener
        ::bind("0.0.0.0:3000")
        .await
        .unwrap();

    println!("Server listening on port 3000");

    axum::serve(listener, app)
        .await
        .unwrap();
}

Call the API from the CLI

The final step of the whole flow is for the CLI to call the API and pass the access token in the Authorization header. Add the following function in auth0-cli/src/main.rs:

async fn call_api(access_token: &str) -> anyhow::Result<()> {
    let client = reqwest::Client::new();

    let response = client
        .get("http://localhost:3000/protected")
        .bearer_auth(access_token)
        .send()
        .await?;

    if response.status().is_success() {
        let body: serde_json::Value = response.json().await?;

        println!("API response:");
        println!(
            "{}",
            serde_json::to_string_pretty(&body)?
        );
    } else {
        println!(
            "API returned {}",
            response.status()
        );

        let body = response.text().await?;
        println!("{}", body);
    }

    Ok(())
}

This code calls the protected route you created in the previous step, passes the access token, and prints the response in the terminal.

Test the Full Flow

To test the flow, first, run the API server from the auth0-api directory:

cargo run

Authenticate using the CLI as before. The CLI will call the API, and you should see the success response:

{
  "message": "You are seeing a protected route",
  "subject": "google-oauth2|123456789"
}

You can find the full app on GitHub.

Rust, Auth0, and Axum Bring Type-Safe Authentication to Your CLI

In this tutorial, you built a complete authentication flow in Rust using Auth0 and Axum. The CLI used Auth0’s Device Authorization Flow to securely authenticate users in a browserless environment, while the Axum API validated the resulting access token before allowing access to protected endpoints. Rust’s type system plays an important role throughout the implementation, with typed API responses preventing malformed OAuth responses from slipping through silently.

From here, you could add refresh token support to keep the CLI authenticated across sessions, extend the Axum server with role-based authorization using Auth0 custom claims, or explore fine-grained authorization for relationship-based access control.

The same Auth0 platform that powers this example also scales to MFA, enterprise SSO, and multi-tenant B2B identity as your needs grow. Check out the Auth0 documentation and the Device Authorization Flow guide to keep building.

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

Cameron Pavey — Sat, 10 Oct 2026 22:15:00 +0000

In April 2026, an AI coding agent deleted the entire production database of PocketOS, a B2B platform used by car rental companies, along with every volume-level backup, in nine seconds. The agent was Cursor, running on a leading frontier model, configured with explicit safety rules its founder later described as "exactly what these vendors tell developers to do." It was working on a routine staging task when it encountered a credential mismatch, found a token with sufficient permissions, and issued a single GraphQL mutation that wiped everything.

The system prompt told it not to do anything destructive without approval, but system prompts are advisory, not enforced. As the post-mortem makes clear, the deeper architectural failure was giving a non-deterministic agent the same access a human operator would have, and trusting natural-language instructions to constrain what it did with that access.

The agent did not behave like a human user. It ran continuously and ignored explicit instructions. It also did not behave like a backend service, as it had no fixed code path and no auditor-readable workflow. The identity layer underneath it had to choose one of those two shapes, because those are the shapes our identity infrastructure offers. It chose wrong, but there was no way for it to choose right, because the right shape did not really exist.

This article makes the case that AI agents need to be treated as first-class identities in their own right, distinct from human users and from traditional machine identities. That case covers why the traditional models break down, what a first-class agent identity consists of, how lifecycle management has to change, why authorization has to be evaluated at runtime against the request rather than baked into roles at provisioning time, and what observability requirements emerge. The goal is not to build a new identity primitive from scratch, but to extend your existing infrastructure to handle a class of actor it was not designed for.

Why the Legacy Models Break Down

OAuth delegation gives the agent the same authority as the user. When a user grants an agent access to their CRM with the scopes they themselves hold, the agent can do anything the user can, across every future interaction, regardless of what it is being asked to do in any specific moment. The intent is selective delegation, but OAuth cannot express it at that granularity. Saying "let the agent see contact details for accounts I'm currently working on, but not anything in the legal holding queue" requires elaborate scope engineering that few products expose.

Service accounts have the opposite problem. The agent gets its own credential, but that credential is typically static, broadly scoped, and disconnected from any user context. When something goes wrong, the audit log shows that the service account did it, which is almost no information at all. There is no way to trace back through the chain of delegation, no way to see which user request triggered the action, and no way to revoke a single agent run without revoking the entire service account.

Both models share four failure modes that worsen as agent usage scales:

Over-permissioning: The credential carries broader authority than the agent needs for the task in front of it, because scopes are typically defined at the resource level (billing:write) rather than the capability level (billing.refund.issue_under_50_usd).
Blast radius: A compromise of the agent process, its memory, or its logs exposes a credential that grants standing access to production systems.
Lack of behavioral context: The identity layer cannot distinguish between "the agent is summarizing tickets" and "the agent is issuing refunds" because both operations present the same broadly-scoped credential that authorizes both actions.
Credential sprawl: Every new tool the agent integrates with means another credential to provision, store, rotate, and audit.

All four failure modes existed before AI agents and have been seen in incidents involving traditional automation. However, agents make them worse for two main reasons.

The gap between the credential's authority and the work the agent is doing at any specific moment is much wider than it is for traditional automation.
The agent's behavior is non-deterministic in a way that conflicts with the assumptions baked into both models.

A service account is safe partly because the code calling it is fixed. An agent's "code" is a tool-calling loop steered by an LLM interpreting natural language input that may itself be untrusted. When you can no longer rely on the determinism of an automation's code, the credential's scoping becomes one of the few remaining constraints on what the agent can do.

What a First-Class Agent Identity Looks Like

A first-class agent identity is more than a service account with a different label. It has its own lifecycle, permissions, policy bindings, and audit trail. It is an identity primitive that is structurally distinct from both users and traditional machine identities.

OpenFGA, the CNCF authorization engine that underpins Auth0's Fine-Grained Authorization product, formalizes this in its authorization patterns for agents. Agents are modeled as first-class principals that participate in the same permission hierarchy as users, with their own type in the authorization model and their own relationships to resources, but with permissions scoped to capabilities and bound to tasks rather than inherited as-is from a user role.

Specifically, a first-class agent identity has four properties:

A directory identifier distinct from any user or service account, with metadata describing the agent type, the agent definition version, and ideally, who is accountable for its behavior.
Scoped permissions defined in business terms, separate from any user's permissions even when the agent is acting on a user's behalf.
Delegation context recording both the agent as actor and the user as subject when the agent acts on someone's behalf. Downstream systems see "agent X, acting on behalf of user Y, with delegated authority Z" rather than just "service account did a thing."
A dedicated audit trail attributing every action to the specific agent identity with the delegation chain intact, separate from the logs the underlying tools generate.

A backend service has a static workflow and code paths that an auditor can read, so a broadly scoped credential is constrained by what the code does. An agent has none of these constraints. Its workflow is determined at runtime by an LLM, and its code path is a tool-calling loop that takes in untrusted input. The credential has to do the work that the code is not doing, and it has to do that work at the request level, not at provisioning time. OAuth 2.0 Token Exchange (RFC 8693) was designed to support this kind of dynamic, request-scoped delegation, and it is the foundation that Auth0's Token Vault builds on.

Lifecycle Management for Ephemeral Actors

User accounts live for years, and service accounts live for the lifetime of the service. Agent identities live somewhere in between, often lower down the spectrum. A long-running agent that handles support tickets might persist for the lifetime of the deployment. A task-scoped agent that runs once to answer a single user query might exist only for the duration of that task.

Provisioning is rarely interactive. Consent happens when a user authorizes an application that uses agents, and the agent identities are created on demand by that application. Provisioning has to be programmatic, idempotent, and tied to the agent definition rather than a human approval workflow.

Execution-context credentials should not be the same credentials that establish the agent's identity. The identity establishes who the agent is and what it could in principle do, while the execution-context credential is a short-lived token, scoped to the operation in front of the agent, that authorizes a particular call. This is the pattern Auth0's Token Vault implements at the OAuth layer: the agent does not hold the long-lived refresh token for a connected service, and instead requests a just-in-time access token through OAuth 2.0 Token Exchange. If the agent is compromised, the only credential exposed is whatever short-lived token it currently holds.

The diagram below shows what this flow looks like in practice. There are two phases. Once, when the application is first authorized, the user grants consent and the identity provider stores the long-lived refresh token in Token Vault, where it stays. Then, for each operation the agent needs to perform, it requests a short-lived access token scoped to that specific operation. The identity provider evaluates the request against policy, returns a token that lasts minutes rather than days, and the agent uses it for a single tool call before discarding it. If the agent is compromised, the attacker inherits only whatever short-lived token happens to be in memory, and revoking the connection at the identity provider invalidates all future token exchanges immediately.

Suspension and decommissioning also have to be easy, fast, and accurate. Recall the PocketOS incident: when the agent went off the rails, there was no equivalent of "revoke the agent's database write capability for the next ten minutes while we figure out what just happened." The credential it was using gave it standing authority, and standing authority can only be revoked at the level of the whole credential. Centralizing token issuance through a single identity provider makes finer-grained revocation possible, since revoking a connection invalidates future token exchanges immediately while leaving the rest of the system running.

Policy-Driven Authorization

Static role assignment is the traditional model for user and service identity: an actor has a role, the role grants permissions, and permissions are checked against actions. This works fine when behavior is predictable, but is inadequate for agents. An agent might have access to a wide set of capabilities in principle, but in any given task, it should only exercise a narrow subset, determined by the task itself.

A better model is to bind authorization to behavior rather than to identity, evaluated at runtime against the specific request. There are two relevant patterns here. Attribute-based access control (ABAC) takes contextual attributes into account: the user the agent is acting on behalf of, the resource, the time, the action, and any task parameters. Relationship-based access control (ReBAC) goes further, expressing authorization in terms of relationships between entities. This makes it natural to write rules like "an agent can read contact details for accounts where it has an active assigned ticket," because the relationship is a first-class concept in the model rather than something encoded through scope engineering.

ABAC alone is enough for most teams. If your authorization rules can be expressed as "this attribute equals that attribute," you may not need the full relational graph. ReBAC pays for itself when you're managing thousands of resource-relationship pairs across a multi-tenant system, where the cost of expressing those rules in any other model becomes prohibitive. For a small team with a single-tenant product and a handful of resource types, a policy engine evaluating attributes against requests will likely cover most of what you want. You may not need ReBAC, but if you are deploying agents, you need some kind of policy-driven, runtime-evaluated authorization, whatever shape that takes.

Auth0's Fine-Grained Authorization, built on OpenFGA, is one of the more developer-accessible ways to do the ReBAC version of this. The authorization model defines types and relations, and condition checks ask whether a specific relationship holds for a specific request. The following is an example of an OpenFGA authorization model definition with a few relationships between users, agents, and accounts, and a condition:

model  
  schema 1.1

type user

type agent

type account  
  relations  
    define owner: [user]  
    define assigned_agent: [agent with active_assignment]  
    define can_read: assigned_agent or owner

condition active_assignment(current_time: timestamp, expires_at: timestamp) {  
  current_time < expires_at  
}

The agent identity participates in the relationship graph as a first-class type. The condition expression incorporates runtime context — in this case, a time-bound assignment that expires automatically. The check happens at the moment the agent attempts an action, not when the agent was provisioned. If the assignment has expired, the check fails and the agent cannot perform the action.

Static permissions cannot keep up with agents that make autonomous decisions in real time. By the time a role change has rolled out to fix an over-permissioning issue, the agent has already acted with the old permissions a thousand times. Policy-driven authorization moves the decision to the moment of the action, where the context is known and the authorization layer can evaluate the specific request rather than against a generalization of expected behavior. That is also what makes the audit trail meaningful: every check is a discrete decision tied to a specific request, not a side effect of role membership configured in advance.

Observability and Non-Repudiation

A user-proxy or service-account model collapses the chain of accountability. The log shows that "the user" or "the service" did something, with no record of which agent was involved or what task it was executing. With a first-class agent identity, the chain is preserved, and three observability requirements become apparent:

Delegation chains must be explicit: Each API call should be traceable back through user → agent → sub-agent → tool → resource, with each hop recorded. OAuth 2.0 Token Exchange supports this, with actor and subject claims expressing the delegation relationship in the token itself.
Decisions must be logged, not just actions: Knowing the end decision is not enough. You also need to know which plan the agent was executing, which tool calls led to that point, what input shaped the decision, and which policy evaluations approved or denied each step. This is closer to distributed tracing than to traditional audit logging.
Non-repudiation must extend to original user intent: When a user authorizes an action, that authorization should be bound to the specific action approved, not to a generic scope. Rich Authorization Requests (RAR) support this by letting the authorization request carry structured details about what is being approved. Combined with Client-Initiated Backchannel Authentication (CIBA) for asynchronous user approval, the audit log can show exactly what the user approved and how the agent executed against it.

Centralized token issuance, as with Auth0's Token Vault, supports all three requirements by routing every credential through a single control plane. Every token is logged with the agent identity, the user it was issued for, the scope, and the time. Every revocation propagates immediately. The audit infrastructure does not have to reconstruct the chain of custody from scattered logs across multiple tools because the identity provider has already recorded it.

Building for Agent Identity

Treating AI agents as first-class identities is no longer a theoretical exercise. The traditional models of user-proxy delegation and static service accounts were not designed for non-deterministic actors that interpret natural language at runtime, and the gaps they leave compound quickly as agents take on more of the work the business depends on. The right response is to extend existing identity infrastructure with primitives designed for the way agents behave: distinct identities with their own lifecycles, policies bound to behavior rather than to roles, and audit trails that preserve the delegation chain from user intent through autonomous action.

Most of the building blocks exist. OAuth 2.0 Token Exchange provides the delegation semantics. CIBA and Rich Authorization Requests provide standards-based approval flows. OpenFGA and similar engines provide the policy infrastructure. Products like Auth0's Token Vault and Fine-Grained Authorization assemble these into developer-accessible platforms, and the patterns documented in OpenFGA's Authorization for Agents guidance show how to apply them in practice.

Organizations need to recognize that the identity model is not an implementation detail to be papered over with whichever credential pattern is most familiar to them. The PocketOS incident was not a freak accident. It was the predictable consequence of applying an identity model to a class of actors it was never designed for. AI agents in production deserve the same care that goes into provisioning user accounts and service identities, with the recognition that they are neither.

Why AI Agents Need Their Own Permission Model

Cameron Pavey — Sat, 10 Oct 2026 09:09:44 +0000

AI agents are rapidly making their way into production systems with access to real customer data, internal tooling, and revenue-impacting workflows. A support automation agent might read tickets from a CRM, summarize conversation history, issue partial refunds, create internal escalation tickets, and post a status update to Slack, all within the span of a single task. When these agents work, they can streamline workflows and compress the cost of routine operations. When they fail, they fail differently than traditional automation: non-deterministically, at scale, and often with full production credentials in hand.

To be useful, an agent needs enough access to execute dynamic, multi-step workflows across multiple tools. But to be safe, it can't operate as a "superuser" with permanent, broad authority over those same tools. Most teams tend to default to access patterns they already know, like long-lived API keys baked into environment variables or OAuth flows designed for human users, and discover quickly that these patterns were never built for non-deterministic software. A misconfigured prompt, a malicious tool response, or a simple hallucination can turn into a significant incident.

This guide teaches you how to apply the least-privilege principle to autonomous systems. You'll learn how to scope permissions to capabilities rather than resources, issue short-lived credentials tied to specific execution plans, separate identity, authorization, and execution into distinct layers, and introduce human-in-the-loop approval for high-risk actions.

The Access Model Mismatch

Traditional access control models assume you are one of two actors:

The first is a human user: interactive, bounded by a session, constrained by a UI, and generally predictable within a single workflow.
The second is a backend service: deterministic, fixed in its workflow, and auditable through static code paths. AI agents fit neither category.

Agents are non-deterministic by design. Two runs of the same prompt against the same data can produce different tool call sequences. They chain tool invocations in ways the developer did not explicitly write, and they can be influenced by untrusted input through two well-documented threat classes:

Prompt injection: Instructions embedded in a document or web page hijack the agent's behavior.
Tool output poisoning: A tool response manipulates subsequent decisions in the chain.

Increasingly, agents also spawn sub-agents, so a delegation chain that starts with a single user request can fan out across many independent contexts before it completes.

The identity primitives built for these two types of actors (session tokens, service accounts, and OAuth scopes) are not broken in isolation; used with strict scoping, mediation, and runtime enforcement, they can work well. The issue is that they were not designed for non-deterministic, multi-step autonomous execution, and their typical usage patterns, which assume a bounded session or a deterministic workflow, do not hold. A session token assumes a bounded interactive flow. A service account assumes deterministic behavior. An OAuth scope like billing:write assumes an application on the other end interprets it as intended by the user.. When an agent inherits any of these without additional layers, it gets authority without the corresponding accountability structures that made the original model safe.

Common Anti-Patterns

Before reviewing better patterns, it's worth looking at the shortcuts teams typically reach for. Each one feels reasonable in isolation, but together, they can be dangerous.

Embedding long-lived credentials

The first common anti-pattern is embedding long-lived API keys directly in agent configurations or environment variables. The agent holds a root credential that grants broad access to a tool, and any compromise of the agent process, logs, or memory exposes that credential. While this is also a problem in non-agentic software, the risk is elevated with agents because, depending on how they are configured, they can be tricked or coerced into taking actions they shouldn’t, or revealing credentials they have access to, much more easily than traditional software with long-lived credentials can be exploited.

Even with rotation in place via something like Vault or AWS Secrets Manager, the real issue is blast radius; rotation is often inconsistent or slow, and the window between compromise and rotation is more than enough for an attacker (or a misbehaving agent) to do significant damage.

Full user OAuth scope inheritance

The second anti-pattern is full user OAuth scope inheritance. A user grants the agent access to their CRM with the permissions they themselves hold, and the agent now has those scopes permanently, across every future action, regardless of what task it is actually performing. The agent inherits authority that the user only ever intended to exercise selectively. However, the agent does not have the discretion, contextual awareness, or accountability that the user has, and it is only a matter of time before the agent accidentally misuses these overly broad permissions.

Agents with effective superuser privileges

The third, and most damaging anti-pattern, is agents operating with effective superuser privileges over the tools they orchestrate, typically at a system-level, rather than an individual user-level. This happens implicitly when you use the most permissive available scope rather than defining a narrower one. The support agent mentioned earlier might be given a billing:write scope because it's the only billing scope available, and now it can issue refunds of any size, modify any customer's payment method, and cancel any subscription, even though its actual job is issuing small goodwill refunds within a narrow policy.

Consider what happens when a support operations agent with billing:write is asked by a user, "Process a full refund for order #12345." The order total is $10,000 USD. With no way to distinguish between refund sizes it's allowed to process, and those it is not, the agent simply proceeds. Nothing in the access layer prevents it. The damage is done in milliseconds, and the only audit trail is a refund record that looks identical to any legitimate one.

Capability-Scoped Permissions

The first step in solving the problem of agent permissions is to stop thinking about permissions in terms of resources and start thinking about them in terms of capabilities. A scope like billing:write describes a resource category and a verb. A capability like billing.refund.issue_under_50_usd encodes a specific action type, a resource limit, and an implicit risk boundary, although you would not typically encode a capability check into a scope like this, due to the inevitable explosion of scopes that would follow.

Capability-scoped permissions express authorization in terms the business actually reasons about. When a product manager decides the support agent should be able to issue courtesy refunds up to $50 USD, that decision should live in a declarative policy that the authorization system evaluates, not scattered through imperative checks in the application code that calls the API. Whether the $50 USD threshold is enforced by the authorization engine itself or by an in-code check, such as a dedicated policy layer that is consulted before token issuance is an implementation detail; what matters is that the rule is centrally managed and auditable.

This is where fine-grained authorization systems come in, and while they solve a specific piece of the puzzle, they're not always an all-in-one solution.

OpenFGA, an open-source authorization engine created by Auth0's FGA team and now a Cloud Native Computing Foundation (CNCF) project, implements Relationship-Based Access Control (ReBAC). ReBAC excels at modelling who can act on what. The support agent isn't just a role, but an entity with specific, bounded relationships to specific resource types, and those relationships produce different permissions. You can express rules like "an agent can refund an order only if the order belongs to a customer with whom the agent has an active ticket."

What pure ReBAC does not do is enforce numeric or attribute-based constraints like "refund amount under $100." OpenFGA extends the base ReBAC model with Conditions, which let you attach predicates to a relation so that numeric limits, time-bounded grants, and contextual attributes are evaluated as part of the authorization check.

In OpenFGA, the two layers in the diagram above collapse into a single check: the relationship and its condition are evaluated together, and either can deny. A capability like "agent can refund orders where amount < configured_limit" can be expressed directly in OpenFGA via a condition, with the amount supplied either in the tuple itself or contextually at check time. For teams that prefer to keep pure authorization policy separate from declarative policy code, a dedicated engine like Cedar or OPA layered on top is a legitimate alternative, but it isn't required; OpenFGA can handle both the relationship graph and the attribute constraints.

Concretely, a support-agent refund capability with a per-agent limit looks like this in OpenFGA's DSL:

model  
  schema 1.1

type user  
type agent  
type customer

type order  
  relations  
    define owner: [customer]  
    define can_refund: [agent with refund_within_limit]

condition refund_within_limit(refund_amount: int, agent_limit: int) {  
  refund_amount <= agent_limit  
}

The capability is granted by writing a relationship tuple that carries the agent's configured limit as persisted condition context. For a support agent with a $50 USD ceiling:

await fgaClient.write({  
  writes: [  
    {  
      user: "agent:support_agent_01",  
      relation: "can_refund",  
      object: "order:12345",  
      condition: {  
        name: "refund_within_limit",  
        context: { agent_limit: 50 },  
      },  
    },  
  ],  
});

At check time, the runtime supplies the request-specific half of the condition context (the actual refund amount being attempted):

const { allowed } = await fgaClient.check({  
  user: "agent:support_agent_01",  
  relation: "can_refund",  
  object: "order:12345",  
  context: { refund_amount: 75 },  
});

OpenFGA merges the two sides when evaluating the condition, with persisted tuple context taking precedence over request context if a key appears in both. With agent_limit: 50 stored in the tuple and refund_amount: 75 supplied at check time, the condition refund_amount <= agent_limit evaluates to false and allowed comes back false; the agent cannot autonomously issue a $75 USD refund, and the runtime's next move is to trigger a human approval flow (covered later in this article) rather than request a refund-capable token.

The practical takeaway is to define capabilities that match actual business boundaries. Not billing:write, but billing.refund.issue_under_50_usd. Not crm:read, but crm.contact.read_for_assigned_tickets. When you catch yourself defining a capability that feels uncomfortably broad, take a moment to consider if you can strip it back to something less permissive, without compromising the functionality you're building.

Task-Scoped Credentials

Capability scoping addresses what the agent can do. Task scoping addresses when and for how long it can do it. These are separate concerns, and conflating them is a common mistake.

A well-designed agent minimizes or eliminates persistent credentials wherever possible. Instead of holding standing access, it requests short-lived tokens tied to each operation's execution plan. The token carries only the capabilities needed for that plan, expires quickly (minutes, not days), and is discarded after use. In practice, some systems still cache short-lived tokens or rely on scoped service accounts for infrastructure concerns. The goal is less about purity, and more about reducing the window in which any given credential is useful.

This pattern has several useful properties:

The window for credential exposure incidents collapses, so a token leaked from an agent's memory is only useful for a short time.
The blast radius of a compromised agent shrinks, because the agent can only act with whatever short-lived token it currently holds.
The agent itself never touches the root credential. A separate component brokers tokens on the agent's behalf, so even if the agent process is compromised, the underlying OAuth refresh tokens or API keys are not.

Auth0's Token Vault implements this pattern at the identity layer. The vault securely stores OAuth tokens for connected services (Google, Slack, Salesforce, GitHub, and others), and the agent requests a just-in-time access token scoped to a specific task rather than handling the long-lived credential itself. Token Vault implements OAuth 2.0 Token Exchange (RFC 8693), giving it a standards-based foundation rather than a proprietary flow. Depending on the flow used, the agent may never touch the underlying refresh token at all; in the access-token-exchange flow designed for SPA-plus-backend architectures, the refresh token stays on the Auth0 side entirely.

For the support agent referenced in this article, this means that when it decides to issue a refund, it does not already hold a refund-capable token. The runtime first evaluates the request against the policy layer, asking questions like: is the amount within the agent's autonomous threshold, is the customer not flagged for fraud review, does the agent have the right relationship to this order, and only then requests a short-lived access token scoped to the refund capability and this specific customer. If the agent is compromised between tasks, there is no standing refund authority to exploit; any earlier token has already expired, and issuing a new one requires passing the policy checks again.

Identity, Authorization, and Execution Are Three Different Layers

A useful clarification when designing agent access control is to recognize that three distinct concerns are often collapsed into one implementation.

Identity establishes who the agent is. It answers the question, "which agent, acting on behalf of which user, is making this request?" Identity is relatively stable; an agent typically has a consistent identity across many tasks.
Authorization determines what an authenticated actor is permitted to do. It answers, "given this identity, what capabilities apply?" Authorization is a policy decision, and it should be evaluated fresh for each operation, not inherited from a long-lived grant.
Execution enforcement determines what is actually allowed in a specific runtime context. It answers, "for this specific call, with this specific payload, does policy permit it?" This includes things like the refund amount, the target resource, and any contextual constraints that cannot be known until the request is actually made.

Conflating these leads to familiar failure modes. If identity and authorization are the same thing, then authority is frozen at authentication time and cannot adapt to the task being performed. Similarly, if authorization and execution are coupled, then policy cannot be centrally managed, audited, or updated. Each layer needs its own boundary, and each boundary should be enforced by a different component.

Architectural Separation

In practice, handling these three concerns means designing three distinct layers in any production agent system.

Identity provider layer

The identity provider layer handles authentication and token issuance. Auth0 authenticates users, manages connected accounts via Token Vault, issues scoped tokens, and handles delegation flows. The identity provider knows who the agent is and what capabilities are available to it, but does not execute business logic.

Runtime environment layer

The runtime environment layer interprets agent plans, requests credentials from the identity provider, and enforces policy before making calls to downstream tools. This is typically your agent orchestration code, often built on a framework like LangChain, LlamaIndex, or the Vercel AI SDK.

In a well-designed system, the runtime is separate from the LLM process itself: the LLM produces tool calls, but the runtime decides whether those calls are permitted, requests credentials for them, and makes the actual API calls. Many real-world agent systems fall short of this, passing API keys into tool wrappers or exposing tokens through tool configuration. Keeping credentials out of the LLM's reach is a design goal worth pursuing deliberately, not a property you get for free.

Tool layer

The tool layer is the downstream system, such as the CRM, billing service, or Slack API, that actually executes the operation. The tool layer is responsible for its own enforcement and logging, independent of whatever the agent or runtime believes is permitted. This defense ensures that even if the runtime is compromised, the tool still enforces its own authorization rules.

When this separation is maintained, it has a critical security benefit: the LLM process itself never holds credentials. The runtime brokers them, presents them for individual API calls, and discards them. A prompt injection attack that tries to convince the LLM to leak "its credentials" has nothing to leak, because the LLM was never given any.

Approval Boundaries for High-Risk Actions

Even with capability-scoped, task-scoped credentials, some actions warrant an extra step: explicit human approval at the moment of execution. This is not a fallback for a broken permission model. It's an intentional design choice for operations whose risk profile justifies the extra friction.

The question is, what actions cross that line. The support agent issuing a $5 USD refund probably should not require human approval; the automation value comes from handling those without intervention. The same agent attempting a $2,000 USD refund, a refund to an account flagged for fraud review, or any destructive action on a customer record is a different matter entirely. These are the operations where getting it right matters more than getting it fast.

Auth0 implements asynchronous approval using the Client-Initiated Backchannel Authentication (CIBA) standard, an OpenID Foundation specification that lets a client (such as an agent backend) request user approval out-of-band from a separate trusted device. Most production agent systems today handle approval through bespoke flows, internal policy engines, or workflow systems like Temporal. CIBA offers a standards-based alternative that slots into existing OAuth infrastructure rather than requiring a parallel approval system. When the support agent identifies that an operation exceeds its autonomous threshold, its backend sends a CIBA request to Auth0. The user receives a push notification on their enrolled mobile device via the Auth0 Guardian app (with sms or email also as supported channels), and the agent polls for a response. If the user approves, the agent receives a token scoped to that specific action. If the user denies or the request times out, nothing happens.

CIBA becomes more powerful when combined with Rich Authorization Requests (RAR), an OAuth 2.0 extension that lets the authorization request carry detailed, structured context about what is actually being approved. Rather than a generic "approve access to billing?" prompt, the user sees something specific, such as "approve refund of $2,000 to customer Jane Doe for order #12345." The structured authorization_details payload makes the approval verifiable and auditable in a way a broad scope grant cannot be.

This pattern directly addresses the $10,000 refund scenario. The agent's capability scope permits refunds under a low threshold autonomously. For anything above that, the agent cannot proceed without triggering a CIBA flow, and the user sees the exact amount and target before approving. The agent cannot bypass this because the token it needs to execute the refund is only issued after approval.

Observability and Control

The final layer is observability. An agent that operates under strict permission controls is still operating autonomously across many systems, and understanding what it did, why, and on whose behalf is essential for debugging, incident response, and compliance.

Three elements matter:

Audit trails should capture agent decisions, not just actions. It's not enough to know that a refund was issued; you want to know which plan the agent was executing, which tool calls led to this point, and what context informed the decision.
Delegation chains should be explicit, so a given API call is traceable back through user → agent → sub-agent → tool → resource, with each hop recorded.
Revocation has to be fast and precise. If an agent is misbehaving, you need to revoke its standing grants, invalidate in-flight tokens, and halt further tool calls, without taking down the entire system.

Auth0's platform provides this infrastructure by centralizing token issuance, which means every token vended to an agent passes through a single control plane. Revoking a connection in Token Vault invalidates future token exchanges immediately, and the audit logs reflect every issuance and use.

A Permission Model for Agents

AI agents require access control models designed for non-deterministic, autonomous workflows. Permissions inherited wholesale from a human user, or from a static service account, are not fit for purpose. The agent will use them in ways neither the user nor the developer anticipated, and the existing access layer will not notice.

The three patterns that form the foundation of production-ready agent architectures are:

capability-scoped permissions that encode specific actions and limits rather than broad resource verbs
task-scoped credentials that are short-lived and tied to specific execution plans rather than persistent grants
layered enforcement that separates identity, authorization, and execution into distinct components

Together, these patterns contain the blast radius of agent mistakes without removing the autonomy that makes agents useful.

Closing the Audit Gap in Human-to-Agent Delegation

Vivek Maskara — Fri, 09 Oct 2026 18:22:49 +0000

When AI agents act on behalf of users, traditional audit logs often don't tell the full story of who actually performed an action. In this article, I explore how to close that gap using Auth0's monitoring, Token Vault, and CIBA approval flows. I also cover how to track delegated actions, manage tokens securely, and maintain a clear audit trail across agent workflows.

AI agents create a new kind of audit gap. When agents act on behalf of a user, they may use tokens issued under that user’s identity, even though the action is executed by the agent. When a high-privilege action shows up in your logs, you need to know whether it came from a human developer, a scheduled backend job, or an AI agent acting with delegated authority. If you only look at traditional audit logs, it can appear that user X did Y, even when the action was carried out indirectly by an agent.

Auditing and traceability get harder as agents operate across identity providers, SaaS platforms, and internal services. A single user request can turn into a chain of delegated actions where intent, authorization, and execution happen in different places. Closing the audit gap means capturing not only what happened, but also who initiated it, how delegation occurred, what permission was used, and what approvals happened along the way.

In this article, you will learn how to use Auth0’s monitoring and logs to capture agent-related activity, how to interpret event types in delegated authorization flows, and how to assemble a practical workflow using Auth0’s built-in monitoring features, logs, and log streams.

Understanding the Audit Gap in AI Agent Systems

Identity models are typically built around a simple flow. A human authenticates, their application receives a token, and calls an API. Even service-to-service calls are usually modeled as explicit machine identities with clear boundaries and predictable lifecycles.

Agentic systems use a similar authentication and authorization model, but the operational context around that delegation changes. You still have a human identity, but you also have an agent that can act for that human, often across multiple external providers. The delegation chain can include a UI action, a background job, a token exchange, and a series of API calls. Many logging pipelines do not represent those handoffs clearly.

The core problem is indirect execution. Attribution gets harder because the actor that initiated intent (the human) and the actor that executed the call (the agent) may not share a runtime, IP, device, or even the same system. For example, when a user asks an agent to pull the latest pipeline from Salesforce and summarize it. The agent would use the stored OAuth 2.0 tokens to call Salesforce APIs. Without explicit delegation context, the audit trail can make the action look like normal user access, even when it was performed by an agent acting on the user’s behalf. For agents, that distinction matters because they may act on a user’s authorization across background workflows, not just in response to a direct click.

Auth0 monitoring and tenant logs help by providing a consistent identity-layer record of authentication, authorization, and delegation-related events. You can correlate token issuance, exchanges, approvals, failures, and downstream activity. Auth0 helps ensure the delegation layer emits enough signals to reconstruct who authorized what, how the agent obtained the ability to do it, and which workflow used that access.

For example, if an agent accesses Google Drive on behalf of a user, you should be able to correlate the user’s original connection to Google, the scopes granted, the token access or refresh event, the agent run ID, and the downstream file access. If the same agent later accesses Salesforce, you should be able to perform the same reconstruction across a different provider. This correlation is what turns disconnected logs into an audit trail.

Monitoring Agent-Driven API Access with Token Vault

Token Vault is designed for applications (and agents) that call external providers like Google or Salesforce on behalf of users. Instead of storing long-lived third‑party refresh tokens in your agent’s database, Token Vault stores provider access and refresh tokens and brokers access to them. Your agent retrieves what it needs at run time to call external APIs under the user’s delegated authorization. This matters because external provider tokens are often the bridge between user intent and agent execution. If every team stores provider refresh tokens in its own service, you quickly lose centralized visibility. You also increase the number of places where sensitive credentials can leak, be misused, or be refreshed without a clear audit trail. Token Vault reduces that sprawl by making token storage and access part of the identity layer, as shown in the diagram below.

When the user first authorizes access to an external provider, Auth0 stores those provider tokens in Token Vault. When the agent later needs to act on the user’s behalf, it retrieves the required token through Auth0. It then uses that token to call the provider API without storing long-lived credentials in the agent backend.

A token vault enables end-to-end audit trails and traceability. Some of its advantages include:

Reduces token sprawl: Centralized storage narrows the number of places where token issuance, refresh, and retrieval can occur.
Helps maintain user context: The agent can act “as the user” without shared service credentials that erase attribution. This does not fully solve the audit gap, but it keeps delegation anchored to a user grant.
Supports asynchronous work without weakening controls: Users authorize once. Agents can operate later. You can still enforce scope and lifecycle controls centrally.
Improves investigation quality: During an incident, investigators can ask which connected account was used, which scopes were available, when the token was accessed, and which agent workflow was running at the time.

Consider a scenario where you are building an agent that can draft a customer follow-up email by pulling context from Google Drive and Salesforce. The user authorizes the required providers once. Later, the agent runs in the background, retrieves the relevant access tokens, reads a document from Google Drive, checks customer details in Salesforce, and drafts a response. With Token Vault in the middle, you will see identity-layer logs worth monitoring:

When the user first connects Google (initial consent and token storage).
When an access token is retrieved for an agent-run task.
When a refresh occurs because the access token has expired.
When scopes change (for example, the agent now needs additional permissions).

If an agent claims it needed Google Drive access, you should see a corresponding event around the same time. If you see repeated refreshes for Google OAuth tokens at unusual hours, that can indicate a loop, an overly broad integration, or a compromised workflow.

Monitoring Approvals in Async Authorization Flows with CIBA

CIBA (Client-Initiated Backchannel Authentication) is a decoupled OAuth/OIDC flow. It lets a client application initiate an authentication or authorization request without the user being present in the same browser session. This fits agent workflows where the agent wants to do something sensitive, but you still want a human approval step before it proceeds. The following diagram shows the CIBA flow in detail:

As shown above, initially, the agent backend sends a backchannel authorization request to Auth0 with the requested scope, binding, and user hint. Auth0 then prompts the user for approval. If approved, the agent receives a token and calls the protected API, while denied or expired requests return an error instead.

CIBA creates explicit, loggable checkpoints in the delegation chain. In a typical “agent just runs” model, you may only see downstream API calls and a token refresh. With CIBA, you can monitor:

When an agent initiated an authorization request: This is an “agent intent” signal that the agent attempted to obtain permission to proceed.
Whether the user approved, denied, or the flow failed/expired: This becomes a clean audit artifact for compliance and incident response.

CIBA fits best when you want agent productivity without silent escalation. For example, if your agent wants to download a customer list from Salesforce and attach it to an internal ticket. Instead of letting the agent use existing tokens silently, you require a CIBA approval with the “export customers” scope.

The agent backend initiates the request.
The user receives a push notification on their phone.
The agent only receives a token that allows the export after approval.
If the request is denied or times out, the agent can fall back to asking the user for a different approach.

To close the audit gap, treat these CIBA events as first-class monitoring signals. In Auth0 logs, look for the sequence of request initiated > pending > approved/denied/expired. Correlate that sequence to token issuance and API activity. Attach a stable correlation ID (agent run ID, job ID, or workflow ID) to the CIBA initiation. Propagate it through internal logs so you can tie “approval granted” to “action executed”. Additionally, you should also decide which actions require CIBA approval. Not every agent action needs a human checkpoint. Reading a calendar to schedule a meeting may be low risk if the user has already granted the right scope. Exporting customer data, sending money, modifying permissions, deleting files, or publishing content may require explicit approval. The goal is to apply approvals where they create meaningful accountability, not to slow every workflow down.

How To Make Delegated Actions Traceable

When working with AI agents, you can do the following to help make delegated actions traceable across identity, application, and provider layers:

Capture identity-layer events in Auth0: Use Auth0 tenant logs to track authentication, authorization, and delegation-related activity via logs.
Centralize external provider tokens: Use Token Vault so token storage, refresh, and retrieval are observable in one place.
Add explicit approvals for sensitive actions: Use CIBA when you need a clear “approved/denied” checkpoint.
Stream logs to your analysis platform: Use log streams to forward Auth0 events to your SIEM (Security Information and Event Management) or data platform.
Propagate correlation IDs end-to-end: Use a stable ID (agent run ID, job ID, workflow ID) across Auth0 initiation, backend execution, and provider API calls.

Auth0 Monitoring Closes the Agent Audit Gap

AI agents create a traceability problem when delegated actions are logged as simple user activity. In third-party integrations, and especially for agentic clients, you need to preserve the difference between the human who authorized access and the system that used it. During an incident, that context helps you answer who authorized the action, which agent or workflow executed it, how access was obtained, and whether a human approved it.

Auth0 provides building blocks to monitor delegated flows at the identity layer. Use monitoring and tenant logs to observe authentication and authorization events. Use Token Vault to centralize external provider tokens used by agents. Use CIBA to add explicit human approvals to asynchronous workflows. With log streams, you can push those events into your data platform and correlate them with application traces and downstream provider audit logs.

Build your agent features so token retrieval, refresh, and approval checkpoints are observable and tied together with correlation IDs. That is the most reliable way to close the audit gap without slowing down developers or agents. Explore Auth0 monitoring and logs today to enhance your visibility and control over agent-driven activities.