DEV Community: Auth0 for Developers

Authentication and Authorization: What's New in .NET 11

Andrea Chiarelli — Mon, 09 Nov 2026 14:13:04 +0000

When it comes to authentication and authorization, .NET 11 focuses on valuable refinements. It addresses key edge cases to enhance security and user experience: a WebSocket that outlives its access token, an authorization attribute that works on one endpoint type but not on another, a passkey list full of identical "Passkey" labels. Let's look at what the newest release brings to authentication and authorization.

Refresh Authentication on Live SignalR Connections

A SignalR connection can live for hours, while an access token usually doesn't. Until now, you had two unattractive options when the token expired: close the connection and make the client reconnect (missing messages in the gap), or leave it open and keep trusting an identity that is no longer valid.

.NET 11 adds a third option: authentication refresh. The client sends the old token over a dedicated /refresh endpoint, and the server swaps the connection's ClaimsPrincipal in place.

You apply authentication refresh when you map your SignalR hub, as shown below:

// Program.cs
app.MapHub<ChatHub>("/chat", options =>
{
    options.CloseOnAuthenticationExpiration = true;
    options.EnableAuthenticationRefresh = true;
});

Setting EnableAuthenticationRefresh adds /chat/refresh next to the existing /negotiate route. If you pair it with CloseOnAuthenticationExpiration, then a connection that fails to refresh in time is closed instead of lingering with stale credentials.

If you run a reverse proxy or a web application firewall, remember to allow the new route. A proxy that forwards /negotiate but blocks /refresh will make every refresh fail.

The server doesn't blindly accept whatever token the client sends. By default, it compares the sub claim (falling back to ClaimTypes.NameIdentifier or ClaimTypes.Upn) of the old and new principals. A refresh that changes the subject is rejected with a 403 status code, so a connection can't quietly turn into a different user.

You can add your own checks with OnAuthenticationRefresh. It can reject a refresh, but it can't approve one that fails the built-in check:

options.OnAuthenticationRefresh = context =>
{
    // Keep the connection inside the tenant it started in
    var sameTenant = context.NewUser.HasClaim("tenant", "contoso");
    return Task.FromResult(sameTenant);
};

On the client side, the .NET client refreshes automatically by default. It asks the server how much lifetime the token has left and schedules a refresh ahead of expiration (five minutes before, unless you change it). Each refresh calls your AccessTokenProvider again, so the provider is where you fetch a fresh token:

var connection = new HubConnectionBuilder()
    .WithUrl("https://example.com/chat", options =>
    {
        options.AccessTokenProvider = GetAccessTokenAsync;
    })
    .WithAuthenticationRefresh(options =>
    {
        options.RefreshBeforeExpiration = TimeSpan.FromMinutes(2);
    })
    .Build();

If you use Auth0, GetAccessTokenAsync is where you'd return a cached access token or use a refresh token to get a new one. The JavaScript client has the same capability through withAuthenticationRefresh and accessTokenFactory. Blazor Server also benefits: interactive circuits receive the refreshed identity without reconnecting, and AuthorizeView re-renders when the roles or permissions change.

Use One Authorization Model Everywhere

You can write a custom attribute that implements IAuthorizationRequirementData and apply it to a Minimal API endpoint to restrict access to it. However, if you apply the same attribute to an MVC controller, a SignalR hub, or a Blazor component nothing is enforced. Before .NET 11, these attributes were only honored on Minimal API and routed endpoints.

In .NET 11, MVC filters, SignalR hubs and hub methods, and Blazor's AuthorizeView and AuthorizeRouteView all evaluate authorization metadata the same way. Under the hood they share a new AuthorizationPolicy.CombineAsync overload:

public static Task<AuthorizationPolicy?> CombineAsync(
    IAuthorizationPolicyProvider policyProvider,
    IEnumerable<object> metadata);

It merges IAuthorizeData, AuthorizationPolicy instances, and IAuthorizationRequirementData attributes using the same rules as the authorization middleware. Take the minimum age attribute from the Microsoft documentation:

class MinimumAgeAuthorizeAttribute(int age) : AuthorizeAttribute,
    IAuthorizationRequirement, IAuthorizationRequirementData
{
    public int Age { get; set; } = age;

    public IEnumerable<IAuthorizationRequirement> GetRequirements()
    {
        yield return this;
    }
}

You write the handler once and the attribute now works across the stack, for example on a hub:

[MinimumAgeAuthorize(21)]
public class PokerTableHub : Hub { }

Notice that an attribute implementing both IAuthorizeData and IAuthorizationRequirementData, like the one above, contributes to the decision only once. Apps that opt out of endpoint routing (EnableEndpointRouting = false) keep the legacy MVC behavior.

The result is fewer surprises when you move an endpoint from one programming model to another. Your policy follows it.

Give Passkeys Meaningful Names

ASP.NET Core Identity gained passkey support in .NET 10, and it came with a small usability problem. Users who registered several passkeys saw a list of credentials with no hint of which device or password manager held which one.

.NET 11 improves this by inferring a display name from the authenticator's AAGUID, the identifier that tells you what kind of authenticator created the passkey. Built-in mappings cover common ones such as Google Password Manager, iCloud Keychain, Windows Hello, 1Password, and Bitwarden. When the authenticator is known, Identity assigns the name automatically. When it isn't, the user lands on a rename page.

If your organization issues its own hardware keys, you can add them to the PasskeyAuthenticators dictionary in your project. It's a small change, but it's the kind of detail that gives a passkey management page a professional look.

Smaller Changes Worth Knowing

A few more items deserve a mention:

TimeProvider in ASP.NET Core Identity. ASP.NET Core Identity now uses TimeProvider instead of DateTime and DateTimeOffset. Register a FakeTimeProvider in your unit tests and you can check lockout durations, token expiration, and security stamp validation without waiting or mocking clocks.
dotnet user-jwts for file-based apps. Running dotnet user-jwts create --file app.cs creates a development JWT for a single-file app with no project file.
TLS channel binding for Negotiate. On HTTPS, Kestrel now passes the TLS channel binding token to the Kerberos or NTLM exchange, which defends against relay attacks. There's nothing to configure. You can also read the token with TryGetChannelBindingBytes on ITlsConnectionFeature.
[ShortCircuit]. This attribute runs an endpoint right after routing and skips the rest of the pipeline, including authentication and CORS. Use it for health checks, never for anything that needs a user.

What Didn't Make It: Device Bound Session Credentials

If you followed the earlier previews, you may remember an experimental package called Microsoft.AspNetCore.Authentication.DeviceBoundSessions. It implemented the Device Bound Session Credentials specification: a short-lived session cookie that the browser can only renew by proving it holds a private key, so a stolen cookie is useless after a few minutes.

The idea is promising, but the package was pulled before RC2. The ASP.NET Core team found the implementation incomplete and may bring it back in a later release. You can follow the tracking issue to keep up to date.

Small Release, Sharper Edges

.NET 11 doesn’t bring any revolutionary changes to authentication, and that's fine. SignalR token refresh removes a trade-off that developers worked around for years. Consistent authorization metadata removes a class of silent gaps. Friendlier passkeys polish the experience that .NET 10 started.

Before you upgrade, check two things: allow the /refresh route in any proxy in front of your hubs, and review any custom authorization attributes you wrote for one endpoint type.

Which of these changes will you use first? Let me know in the comments.

You're Probably Doing Backend-for-Frontend (BFF) Wrong

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

The Backend for Frontend (BFF) pattern is crucial for securing modern applications, but it's widely misunderstood. In this video, we dive into the common pitfalls developers face when implementing BFFs. We break down why PKCE is not a replacement for a BFF, clarify the difference between a true BFF and a simple reverse proxy, and settle the debate on whether cookies are actually less secure than tokens. If you want to ensure your web apps are truly secure against XSS and token theft, this deep dive is for you.

What You'll Learn

Why PKCE protects authorization codes in transit, but doesn't secure token storage.
The critical distinction between a reverse proxy (token mediation) and a proper BFF.
The modern reality of HttpOnly cookies vs. localStorage tokens for XSS protection.
The security responsibilities you still have after implementing a BFF (like CSRF protection and session invalidation).
How to adopt the BFF pattern incrementally without rewriting your entire application.

Resources

Auth0 Blog Post: Things Developers Get Wrong About the Backend for Frontend Pattern
Checkout the Confused Developer Playlist for more videos like this.

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.