DEV Community: Auth0

Implementing the Device Authorization Flow with Auth0 in a C# Console App

Andrea Chiarelli — Mon, 15 Jun 2026 08:01:01 +0000

The redirect-based OAuth 2.0 flows assume one thing: the user has a browser on the same device where your app runs. Smart TVs, IoT sensors, and CLI tools break that assumption. If your application runs somewhere a browser isn't practical or doesn't exist, you need a different mechanism.

The Device Authorization Flow (standardized in RFC 8628) was designed for exactly this scenario. It lets a constrained device initiate authentication and then wait while the user completes it on a separate device with a browser.

By the end of this tutorial, you'll have a working .NET 10 console application that authenticates users through Auth0 without requiring a browser on the device itself.

How the Device Authorization Flow Works

The flow introduces two parallel channels. The device handles polling; the user handles authorization in a browser. These two channels synchronize through a short-lived code.

Here's how those two channels interact:

Let's walk through what each step does:

The user launches your app.
Device code request. Your app sends its client_id to Auth0's /oauth/device/code endpoint.
Auth0 responds with a device_code (used internally for polling), a short user_code (shown to the user), a verification_uri (where the user will navigate to authorize the device), and a polling interval in seconds.
User activation. Your app displays the verification_uri and user_code.
Polling. While waiting for user authentication, your app polls /oauth/token with the device_code.
Until the user completes authorization, Auth0 returns {"error": "authorization_pending"}. The interval field in the initial response specifies the minimum seconds between polls.
The user opens a browser on any convenient device (a phone, laptop, anything with a browser) navigates to that URL.
The user enters the code.
The user is confirmed that the device has been authorized.
Token delivery. Once the user authenticates and approves the device, the next successful poll returns an access token, an ID token, and optionally a refresh token.

Polling faster than the specified interval triggers a slow_down response. When that happens, increase your interval.

A key point to understand: Auth0 never issues tokens to the device until a real user explicitly approves the request in a browser. The user_code is the artifact that ties the device's session to the browser's session. If there is no code exchange, there’s no token.

The Sample Project

Now that you have a good understanding of the Device Authorization flow, let’s build a .NET 10 console application that:

Requests device authorization from Auth0
Displays the activation URL and user code to the operator
Polls Auth0 until the user completes authorization
Retrieves and displays the authenticated user's profile using the resulting access token

The complete sample uses the Auth0 .NET Authentication API SDK (Auth0.AuthenticationApi), which wraps the device authorization endpoints directly.

Register with Auth0

Before writing any code, you need an Auth0 application configured for the Device Authorization flow.

If you don’t have an Auth0 account, you can sign up for free! Then, follow these steps:

Log in to your Auth0 Dashboard and go to Applications > Applications.
Click Create Application, name it (e.g., "Device Flow Demo"), and select Native as the application type. Click Create.
On the Settings tab, copy your Domain and Client ID: you'll need both shortly.
Scroll down to Advanced Settings > Grant Types. Make sure Device Code is enabled (see the picture below). Save any changes.

That's all the configuration the Device Authorization flow requires. Unlike redirect-based flows, this one doesn't need callback URLs or allowed origins, because no browser redirect happens on the device.

Add the Device Authorization Flow to Your App

Now you are ready to implement the Device Authorization flow in your console application. Create a new console project and add the Auth0 .NET Authentication SDK by running the following commands in a terminal window:

dotnet new console -n DeviceFlowApp
cd DeviceFlowApp
dotnet add package Auth0.AuthenticationApi

Open Program.cs and replace its contents with the following code:

// Program.cs

using Auth0.AuthenticationApi;
using Auth0.AuthenticationApi.Models;
using Auth0.Core.Exceptions;

var domain = "YOUR_AUTH0_DOMAIN";
var clientId = "YOUR_CLIENT_ID";

using var client = new AuthenticationApiClient(domain);

var deviceCodeResponse = await client.StartDeviceFlowAsync(new DeviceCodeRequest
{
   ClientId = clientId,
   Scope = "openid profile email"
});

Console.WriteLine("Activate this device:");
Console.WriteLine($"  Visit:      {deviceCodeResponse.VerificationUri}");
Console.WriteLine($"  Enter code: {deviceCodeResponse.UserCode}");
Console.WriteLine();
Console.WriteLine($"  Or open: {deviceCodeResponse.VerificationUriComplete}");

This first block requests the device code and displays the activation instructions.

Replace YOUR_AUTH0_DOMAIN and YOUR_CLIENT_ID placeholders with the values you got in the Auth0 dashboard.

The StartDeviceFlowAsync() method calls the /oauth/device/code endpoint and returns a DeviceCodeResponse containing the activation details. The Scope = "openid profile email" requests the standard OpenID Connect claims needed to read user profile information. Adjust this based on what your app needs.

After receiving the response from Auth0, the application shows the verification URI and the code that the user must provide to authorize your application running on this device. The VerificationUriComplete embeds the user code in the URL directly, which makes it suitable for QR code generation on devices with a display.

Get an Access Token

With the device code in hand, the next step is to poll Auth0 until the user authorizes the device. Start with the basic polling structure:

// Program.cs

//...existing code...

var pollingInterval = TimeSpan.FromSeconds(deviceCodeResponse.Interval);
AccessTokenResponse? tokenResponse = null;

Console.Write("\nWaiting for authorization");

while (tokenResponse == null)
{
   await Task.Delay(pollingInterval);

   tokenResponse = await client.GetTokenAsync(new DeviceCodeTokenRequest
   {
       ClientId = clientId,
       DeviceCode = deviceCodeResponse.DeviceCode
   });
}

This works for the happy path, but GetTokenAsync() will throw an exception when Auth0 returns authorization_pending or slow_down. Replace the while block with this version:

// Program.cs

//...existing code...

while (tokenResponse == null)
{
   await Task.Delay(pollingInterval);

   // 👇changed code
   try
   {
       tokenResponse = await client.GetTokenAsync(new DeviceCodeTokenRequest
       {
           ClientId = clientId,
           DeviceCode = deviceCodeResponse.DeviceCode
       });
   }
   catch (ErrorApiException ex) when (ex.ApiError?.Error == "authorization_pending")
   {
       Console.Write(".");
   }
   catch (ErrorApiException ex) when (ex.ApiError?.Error == "slow_down")
   {
       pollingInterval += TimeSpan.FromSeconds(5);
       Console.Write(".");
   }
}

Here are the main points of this code:

authorization_pending is the expected response while the user hasn't acted yet. It's not a terminal error; it means keep waiting.
slow_down means you exceeded the polling rate. The OAuth spec requires adding at least 5 seconds to the interval when this occurs.
deviceCodeResponse.Interval gives the minimum polling interval Auth0 requires, typically 5 seconds. Starting from this value keeps you within rate limits from the first poll.

Once you receive the access token, use it to get the user profile information. Add the following code after the loop:

// Program.cs

//...existing code...

Console.WriteLine("\n\nDevice authorized!");

var userInfo = await client.GetUserInfoAsync(tokenResponse.AccessToken);
Console.WriteLine($"Signed in as: {userInfo.FullName} ({userInfo.Email})");
Console.WriteLine($"Access token: {tokenResponse.AccessToken[..20]}...");

GetUserInfoAsync() calls Auth0's /userinfo endpoint using the access token and returns the profile claims you requested in Scope. This confirms the token works and identifies the authenticated user.

Test Your Application

Now, run your application with dotnet run. The initial expected output will be similar to the following:

Activate this device:
  Visit:      https://YOUR_AUTH0_DOMAIN/activate
  Enter code: HBTC-NDWC

  Or open: https://YOUR_AUTH0_DOMAIN/activate?user_code=HBTC-NDWC

Waiting for authorization...

Open a browser on another device, or click the link if you are on a machine with a browser. You will see the following screen:

You will be asked to log in to confirm the code. After authentication, the polling loop picks up the tokens on its next iteration and exits. The following message will be added to your application’s output:

Device authorized!
Signed in as: Jane Smith (jane@example.com)
Access token: eyJhbGciOiJkaXIiLCJl...

Get an Access Token for Calling a Protected API

The access token obtained with the current code only allows you to query the Auth0 /userInfo endpoint to retrieve user profile information. In reality, this call is not strictly necessary: you'd typically read user profile claims directly from the ID token rather than making a round trip to /userInfo. The call above is useful for confirming the token is valid and seeing who authenticated. If you want to inspect the raw ID token, print tokenResponse.IdToken and decode it at jwt.io. You can do this as an exercise.

If your application needs to access a protected API, you will need an access token for that specific API. Getting an access token for this is pretty easy: once you have the API’s audience identifier, simply add the setting highlighted below to your authorization request:

// Program.cs

using System.Net.Http.Headers;  //👈 new using

//...existing code...

var deviceCodeResponse = await client.StartDeviceFlowAsync(new DeviceCodeRequest
{
   ClientId = clientId,
   Scope = "openid profile email",
   Audience = "YOUR_API_AUDIENCE"  //👈 new setting
});

//...existing code...

You should also add the scopes you need for accessing the API based on the business logic of your application.

That’s it! Now your application can call the protected API like in the following example:

// Program.cs

//...existing code...

using var httpClient = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Get, "https://your-api.com/endpoint");
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", tokenResponse.AccessToken);

var response = await httpClient.SendAsync(request);
Console.WriteLine($"\nAPI response status: {(int)response.StatusCode} {response.ReasonPhrase}");

Where To Go Next?

You now have a working foundation for Device Authorization Flow in .NET. A few directions from here:

Refresh tokens. If your app needs to stay authenticated across sessions, configure your Auth0 application to issue refresh tokens and use GetTokenAsync(new RefreshTokenRequest { ... }) to renew the access token without user interaction.
Handling token expiry. The device code itself expires (deviceCodeResponse.ExpiresIn seconds from issuance). Handle the expired_token error from the polling loop and restart the flow when needed.
Auth0 .NET SDK reference. The Authentication API SDK documentation lists all available methods and models, including request options for StartDeviceFlowAsync() and GetTokenAsync().
The spec. RFC 8628 is concise and readable. If your production implementation needs to handle edge cases (concurrent sessions, revocation, device re-authorization) it's worth consulting directly.

The Many Faces of OAuth 2.0 Token Exchange

Andrea Chiarelli — Wed, 03 Jun 2026 16:09:41 +0000

Most developers face the need for token exchange when their architecture outgrows its initial assumptions. You have a service that holds a token for one purpose, and now it needs a different token for a different purpose. While simply forwarding the existing token or creating a fresh one might seem like intuitive solutions, both methods introduce significant issues. The OAuth 2.0 Token Exchange flow, as specified in RFC 8693, was explicitly created to address these challenges.

Token exchange gives you a standards-based mechanism for converting one security token into another. The concept is straightforward: a client sends a token to the authorization server and receives a different token back, scoped for a different context, audience, or purpose. But behind this simple operation lie several distinct scenarios, each with its own trade-offs and security implications.

Let's walk through the use cases that make token exchange essential in modern architectures, and see how they connect to solutions available today.

What Is Token Exchange

At its core, OAuth 2.0 Token Exchange is a protocol extension that turns the authorization server into a Security Token Service (STS), i.e., a service capable of validating security tokens provided to it and issuing new security tokens in response. The flow is straightforward: A client sends a subject_token, optionally accompanied by an actor_token, and receives a new token appropriate for the target context. The subject_token is the token representing the user or entity on whose behalf the request is being made; the actor_token identifies the party performing the exchange.

The specification defines two fundamental modes of operation:

Impersonation: The requesting party receives a token that makes it indistinguishable from the original subject. The downstream service has no way to tell whether the actual user or an impersonating party is making the call.
Delegation: The requesting party receives a token that preserves both identities. The downstream service knows who the user is and who is acting on their behalf, typically through an act (actor) claim embedded in the new token.

This distinction matters more than it might seem at first glance. Impersonation is powerful but opaque; delegation is more constrained but auditable. The choice between them shapes your security posture and your ability to trace what happened when something goes wrong.

Administrative Impersonation

Let's start by exploring the first intuitive use case: a customer reports that their dashboard shows incorrect data, but only for their account. Your support engineer needs to see exactly what the customer sees, with the same permissions and data access, to diagnose the issue.

This is the classic administrative impersonation scenario. An administrator exchanges their own token for one that represents the customer's identity. The resulting token carries the customer's sub claim, their scopes, and their audience. From the application's perspective, the request is coming from the customer.

The token exchange request in this case uses only a subject_token (identifying the user to impersonate) and provides no actor_token, because the intent is full impersonation. The authorization server validates that the requesting party has impersonation privileges and issues a token bound to the target user's identity.

There's a problem, though: because this is true impersonation, you lose the audit trail of who actually performed the actions. The downstream service cannot distinguish between the real user and the admin. This is why impersonation-based token exchange should be paired with external logging mechanisms that record who initiated the exchange, when, and for what reason. Without that, you're creating a security gap in the name of troubleshooting.

Managing Protocol Transition

Organizations rarely get to start from scratch. Legacy systems persist, and with them persist older protocols. A common scenario is transitioning from SAML-based authentication to OpenID Connect (OIDC) while keeping both systems operational during the migration.

Token exchange handles this gracefully. A service that authenticates users via SAML can exchange the SAML assertion for an OAuth 2.0 access token. The authorization server validates the incoming SAML artifact and issues a standard access token that downstream services understand.

The subject_token_type parameter in the exchange request identifies the format of the incoming token. RFC 8693 defines several token type identifiers, including urn:ietf:params:oauth:token-type:saml2 for SAML 2.0 assertions and urn:ietf:params:oauth:token-type:jwt for JWT tokens. This flexibility means the authorization server can accept tokens from different protocol families and normalize them into a consistent format for your modern services.

In practice, this pattern appears during company acquisitions and mergers where two organizations with different identity stacks need to interoperate before a full migration is complete. Rather than forcing all users to re-authenticate against a new system, token exchange bridges the gap: users authenticate as they always have, and the system translates their credentials into whatever the consuming service requires.

Chaining Service Calls

This is where token exchange becomes indispensable for most teams. You have a microservices architecture where Service A receives a user request, processes it, and needs to call Service B on the user's behalf. Service B might then need to call Service C.

The following diagram summarizes this scenario:

The question is: what credentials does each service use when calling the next one?

There are three options, each with clear trade-offs.

Option 1: The service uses its own credentials

Service A calls Service B using its own client credentials, ignoring the user context entirely. This is the simplest approach and works well for service-to-service calls that don't need user context (batch processing, system health checks, data synchronization).

However, this option has a problem when a user is involved or your services need the full context. If Service A uses its own credentials, Service B cannot enforce user-level authorization. It doesn't know which user triggered the request, so it can't check whether that user should have access to the requested resource. You've lost the security context that makes accurate authorization possible.

Option 2: The service impersonates the user

Service A passes the user's original token directly to Service B, or exchanges it for a token that makes Service A indistinguishable from the user. Service B sees a request that appears to come from the user and applies user-level authorization.

In this case, the problem is that Service B cannot distinguish the user's direct actions from actions taken by Service A on the user's behalf. If Service A is compromised, it can make any call the user is authorized to make with no way for downstream services to apply different trust levels to direct vs. proxied requests. You've preserved the user context but lost the service context.

Option 3: The service acts on behalf of the user (Delegation)

Service A exchanges the user's token for a new token that identifies both the user (as subject) and Service A (as actor). The resulting token carries an act claim that tells Service B: "This request is about User X, performed by Service A."

This is the delegation model, and it's the one RFC 8693 was primarily designed to support. Service B can now make nuanced authorization decisions: "User X can read this data, and Service A is authorized to act on User X's behalf, so this request is allowed." If Service A tries to access something the user hasn't authorized it to do, the request fails.

The act claim is nestable, meaning that if Service B then calls Service C on behalf of the user, the delegation chain grows: Service C sees that Service B is acting on behalf of User X with Service A as the original actor. This chain provides a complete audit trail of how the request propagated through the system.

The trade-off here is complexity. Each hop requires a token exchange, which adds latency and requires each service to be registered as a client with the authorization server. But for architectures where security and auditability matter (and they always should), delegation is the principled choice.

Token Exchange and Federated Identity

The chain-of-calls scenario becomes significantly more complex when services span security domains, for example, when services are provided by third-party organizations. Consider the situation shown by the following diagram:

Service A has a token to access Service B on behalf of a user in MyCompany’s security domain.
Service B needs to call Service C, which is protected in the External Provider’s domain.
Service B needs an access token valid in MyCompany’s domain to access Service C on behalf of the user.

This is the federated identity challenge. The token that Service B received from MyCompany's authorization server means nothing to the External Provider’s domain. A token issued by one authorization server is not automatically accepted by another, and for good reason: trust boundaries exist to limit blast radius.

In a standard token exchange, Service B would present its token to the External Provider's authorization server and request a new token. But the External Provider's authorization server has no reason to trust a token issued by MyCompany unless a trust relationship has been explicitly established.

Solving this requires federation at the authorization server level. External Provider's authorization server must be configured to accept tokens from MyCompany domain as valid subject tokens in an exchange request. This involves pre-established trust (through metadata exchange, certificate validation, or direct configuration) and mapping between the identity representations in each domain.

In practice, this is where token exchange alone starts showing its limitations. Each cross-domain hop requires explicit trust configuration. As the number of domains grows (enterprise integrations, SaaS ecosystems, multi-cloud deployments), the matrix of bilateral trust relationships becomes unmanageable.

Cross App Access and Identity Chaining

This scaling problem is precisely what Cross App Access (XAA) aims to solve. XAA implements the Identity Assertion JWT Authorization Grant, an OAuth extension that introduces a mediator into the cross-domain exchange: the enterprise identity provider (IdP).

The key insight is that the IdP already knows about both applications and the user's relationship to each. Rather than requiring every pair of domains to establish bilateral trust, XAA centralizes access decisions in the IdP. Let's see how this works concretely.

The flow involves four parties:

Requesting App: The application (or AI agent) in MyCompany domain that needs to access a resource in another domain (External Provider).
Enterprise IdP: The identity provider in MyCompany domain that authenticates employees and manages cross-app policies.
Resource App: The application that owns the protected API in the External Provider domain.
Resource Authorization Server: The authorization server that issues access tokens for the Resource App's protected API in the External Provider domain.

The following diagram shows how the exchange unfolds:

Here is the description of each step:

The employee logs in to the Requesting App via SSO and obtains an ID token from the IdP.
The Requesting App sends that ID token back to the IdP, asking for a cross-domain identity assertion (an ID-JAG, a special JWT scoped for cross-app use).
The IdP checks its XAA policy: is this Requesting App allowed to access the Resource App on behalf of this user? If yes, it returns the ID-JAG.
The Requesting App presents the ID-JAG to the Resource App's authorization server.
The Resource App's authorization server validates the ID-JAG (using the IdP's public keys via OIDC discovery) and issues an access token.
The Requesting App calls the Resource App's API with that access token.

Notice the critical difference from plain token exchange: in step 3, the IdP enforces a policy decision. An administrator explicitly configures which apps can reach which resources, giving IT visibility and control over cross-app data sharing. Users don't face repetitive consent flows, and the organization maintains a centralized view of who can access what.

Identity Chaining is the broader term for this pattern: the user's identity assertion flows from the original authentication through every downstream service in a standardized way, without requiring ad-hoc trust configuration at each boundary. XAA is one concrete implementation of identity chaining, built on OAuth primitives.

This approach is particularly relevant in scenarios involving AI agents, where a single user request might trigger calls to services across multiple third-party providers, each with their own security domain.

Token Exchange and Auth0

Auth0 implements token exchange through mechanisms that address different points in the spectrum we've discussed.

Custom Token Exchange

Custom Token Exchange implements RFC 8693 on Auth0's /oauth/token endpoint with full developer control over the validation logic. You define a Token Exchange Profile that maps a subject_token_type URI to a custom Action. When a token exchange request arrives, Auth0 invokes your Action code to validate the incoming token, enforce authorization rules, and associate it with a user in your tenant.

This is the mechanism for protocol transitions and custom federation scenarios. Auth0 treats the subject_token as an opaque string, meaning you can accept any token format: JWTs from another identity provider, SAML assertions from a legacy system, or proprietary tokens from a partner's API. Your Action code owns the validation logic, and Auth0 handles the issuance of a standards-compliant token on the other side.

Check out this article for practical introduction to Custom Token Exchange in Auth0.

Token Vault

For the AI agent scenario, where services need to call third-party APIs on behalf of users across multiple providers, Auth0 offers Token Vault. This builds on token exchange but adds secure storage and automatic lifecycle management for third-party tokens.

The flow works like this: a user authenticates and connects their accounts (Google, GitHub, Slack, Microsoft, and others). Token Vault stores the resulting tokens securely and handles refresh automatically. When an AI agent needs to call a third-party API on behalf of that user, it performs a token exchange to retrieve a valid access token from the vault.

The resulting token includes an act claim that identifies the AI agent, creating an audit trail of which agent accessed which service on behalf of which user. This is critical for enterprise deployments where compliance requires knowing not just what happened, but what automation triggered it.

Take a look at this article for a quick introduction to Token Vault.

On-Behalf-Of Token Exchange

For the service chain scenario, Auth0's On-Behalf-Of (OBO) token exchange implements the delegation pattern directly. A middle-tier service exchanges the incoming user token for a new token scoped to the downstream API, preserving the user's identity while adding itself to the delegation chain via the act claim.

Auth0 supports up to five levels of delegation chain nesting, providing visibility into the full path a request takes through your architecture. Each token in the chain carries the sub claim (maintaining user identity), the aud claim (scoped to the target service), and the nested act claim (recording the chain of services involved).

Cross App Access

For the federated identity scenario, where a requesting application needs to call a resource API protected by a different authorization server, Auth0 supports Cross App Access (XAA). This feature implements the Identity Assertion Authorization Grant OAuth extension, enabling applications and AI agents to obtain tokens for cross-domain API calls without requiring users to go through repetitive consent flows.

The mechanism works through Auth0 acting as the Resource Authorization Server. When the Requesting App needs to reach a Resource App registered with Auth0, it sends the user's ID token to its IdP, such as Okta, and receives an ID-JAG (Identity Assertion JWT) in return. The IdP issues this assertion only if an administrator has configured the cross-app connection in the Admin Console. The Requesting App then presents the ID-JAG to the Resource App's authorization server, i.e., Auth0, which validates it via OIDC discovery and issues a scoped access token.

This gives IT centralized visibility into cross-app data sharing. Administrators define which applications can reach which resources, and Auth0 enforces those policies at exchange time.

Choosing the Right Approach

Token exchange is not a single solution but a family of patterns. The right choice depends on what context you need to preserve and what trust boundaries you need to cross:

Administrative impersonation when troubleshooting requires seeing exactly what the user sees
Protocol transition when bridging legacy and modern identity systems during migrations
Delegation when service chains need user context with full auditability
Cross App Access / Identity Chaining when delegation spans multiple security domains
Token Vault when AI agents need managed access to third-party APIs on behalf of users

The spread of AI agents has made token exchange more relevant than ever. An AI agent that orchestrates actions across multiple services and multiple providers on a user's behalf is, fundamentally, a delegation chain. The mechanisms we've discussed provide the security foundation for making that chain auditable, authorized, and scoped to what the user actually intended.

The token exchange specification gives us the vocabulary. Implementations like Auth0's give us the tools. The choice of which pattern to apply at each boundary is yours.

How to Decode, Encode, and Validate JWTs inside Claude Code

Jessica Temporal — Fri, 29 May 2026 17:42:15 +0000

Stop context switching and start debugging. Let me show you how to supercharge your AI agent with JWT Skills. Learn how to decode, encode, and validate JSON Web Tokens (JWTs) directly within your terminal session using Claude Code. Whether you're troubleshooting an expired token or testing a custom claim, these tools bring security insights right into your development flow.

What You'll Learn:

How to install the jwt-skills
Decoding tokens to inspect headers, payloads, and claims.
Identifying security flags like expired tokens or PII in payloads.
Generating test tokens with custom claims for edge-case testing.
Validating tokens against JWKS endpoints for production-level checks.

Resources:

🛠 Get the Skills
📖 JWT Deep Dive

Your Team's Productivity Metric is Probably Useless

Carla Urrea Stabile — Wed, 20 May 2026 13:38:00 +0000

If your team is measuring developer productivity by lines of code or number of commits, you're measuring the wrong thing. So what should you be looking at instead?

In Episode 5 of Making Software, I talked to Dennis Henry, Productivity Architect at Okta. Dennis has a master's degree in human factors, and he explained to me how he applies it to software engineering every day.

The science of failure, applied to your codebase. Human factors studies how people interact with systems and how things go wrong. Dennis explains why "human error" is never the real root cause in production incidents, and what you should be looking for instead.
A multi-model AI gateway for an entire company. Dennis built an internal platform that gives every Okta employee secure access to any Anthropic, OpenAI, and more models, that lives behind SSO with PII guardrails and MCP call auditing. He walks through why locking into one vendor right now is a mistake and how to architect around that.
Improving Engineering Productivity Dennis constantly asks engineers: "What pisses you off? What makes you want to throw your keyboard across the room?" He makes the case that happy people make the best software, and that measuring sentiment matters more than measuring output.
What to actually track. Lines of code? Terrible. Commits? Meaningless. Dennis argues for reliability, bug resolution time, customer experience, and whether your team feels like they have the tools to do their job. Qualitative over quantitative.

Productivity isn't about squeezing more output out of people. It's about removing the things that get in the way of meaningful work.

What's the worst productivity metric you've seen used on a team? Let me know in the comments!

Listen to the full episode

Available on YouTube, Apple Podcasts, and Spotify.

Thanks for reading! 👋

What AI Tools, MCP Servers, and Skills Actually Do

Andrea Chiarelli — Tue, 19 May 2026 13:39:13 +0000

I remember being very confused when I first heard about an LLM's ability to request code execution. This feature has been called various names: tool, action, plugin, function. Now the terminology is settling on a single name: tool. However, talking to other developers and reading comments online, I see the confusion has shifted elsewhere. Some argue that, with the introduction of skills by Anthropic, MCP no longer makes sense, and others aren't convinced of the usefulness of MCP compared to direct tool calls.

The confusion is architectural. Tools, MCP servers, and skills solve different problems at different layers.

AI Tools Are the Model's Swiss Army Knife

At the most fundamental level, an AI tool is a function that a language model can decide to call. Not a metaphor for "capability" in general, but a specific, callable function with a defined input schema and a predictable output.

When a model needs information or an action it can't produce from training alone, it generates a structured call to a tool: something like "call get_customer_record with customer_id: 12345." The host application intercepts that call, runs the actual function, and returns the result to the model. The model then incorporates it and continues.

While the tool calling concept is the same across the different LLMs, each one has its own specifications to invoke tools. Check out OpenAI, Claude, or Gemini documentation for some specific examples.

Tools are what give AI its "hands." Without them, a model is impressively articulate but isolated from live data and the systems where real work happens. With them, it can search databases, call APIs, send messages, or trigger business logic in response to what a user needs.

The key property to hold onto: a tool should know how to execute one thing. It doesn't decide when to be called. That judgment belongs to the model, or in more complex systems, to something above it.

Here's what that looks like in code. Using the Anthropic SDK, you define a tool as a JSON schema: its name, a description the model uses to decide when to invoke it, and the inputs it expects:

import anthropic

client = anthropic.Anthropic()

tools = [{
   "name": "get_customer_record",
   "description": "Retrieve a customer's account details by ID",
   "input_schema": {
       "type": "object",
       "properties": {
           "customer_id": {"type": "string", "description": "The unique customer identifier"}
       },
       "required": ["customer_id"]
   }
}]

response = client.messages.create(
   model="claude-opus-4-6",
   max_tokens=1024,
   tools=tools,
   messages=[{"role": "user", "content": "Look up customer C-12345"}]
)

# When the model decides to use the tool, it returns a structured tool_use block
tool_use = response.content[0]
print(tool_use.name)   # get_customer_record
print(tool_use.input)  # {"customer_id": "C-12345"}

A few things to notice:

description: This is what the model reads to decide whether to call the tool. A clear, accurate description matters more than the schema itself.
input_schema: The structured contract. The model generates arguments that conform to this schema when it decides to invoke the tool.
tool_use block: What the model provides when it wants to call a tool. Your application handles the actual execution and passes the result back in the next turn to continue the conversation.

The model never runs the function itself. It produces a structured intent. Your application does the work.

MCP Servers Are the Universal Translator

At first glance, an MCP server might look like a more elaborate way to define tools. In practice, it solves a different problem.

The Model Context Protocol (MCP) is an open standard that introduces a protocol layer between AI applications and the services they connect to. Think of it as USB-C for AI: a universal connector that lets any compliant client communicate with any compliant server, regardless of which model runs underneath.

Without MCP, every AI application builds its own integrations: a custom function schema for one client, a different one for another, yet another for whichever agent framework a team has chosen. The same capability gets re-implemented for each consumer. MCP exists to eliminate that duplication.

Here's how the architecture works:

MCP clients are the components that hosts (i.e., AI applications such as Claude Desktop, a VS Code extension, a custom agent, etc.) instantiate to initiate connections to servers.
MCP servers expose three types of primitives:
- Tools: actions the AI can invoke.
- Resources: data the AI can read.
- Prompts: pre-built interaction templates.

The MCP transport layer is equally flexible. The protocol runs over standard I/O for local processes, or HTTP with Server-Sent Events for remote services, using OAuth 2.1 for authentication on remote connections.

What makes MCP structurally different from direct tool definitions is decoupling. A tool definition embedded in a model API call is tightly coupled to that application. An MCP server is portable: the same server works across any compliant client. Build a GitHub integration once, connect it everywhere.

There's also the matter of bidirectionality: an MCP server can request that the AI client sample from the language model, enabling interactions that go beyond a simple request-response pattern like an API. It's a more symmetric relationship than direct function calling, which flows strictly from model to function.

AI Skills Direct the Work

Skills occupy a different layer from tools and MCP servers entirely.

Where a tool is a capability and an MCP server is the infrastructure for exposing it, a skill is closer to a recipe: higher-level instructions that tell an AI when and how to use its available capabilities to accomplish a complex goal. A skill doesn't replace tools. It orchestrates them.

In practice, a skill combines three things:

System prompts: Instructions that define a persona and a set of constraints.
Logic/Workflows: A series of steps the model should follow.
Tool selection strategy: Knowing which tool to pick in a specific sequence to achieve a complex goal.

Consider a customer support scenario. Handling a refund request might involve checking the customer record, looking up the original transaction, verifying return eligibility based on policy, and then either initiating the refund or escalating to a human, as shown in the following diagram:

Each step might invoke a different tool. The skill is the framework that defines the sequence, the conditions, and the decision points. Skills carry the domain knowledge and reasoning structure that raw tool access doesn't provide.

Anthropic formalized the skills concept for Claude Code, and the format is now an open standard gaining adoption across AI coding tools. The refund scenario above could be expressed as in the following example:

---
name: handle-refund-request
description: "Handle a refund request from the user."
---

You are a customer support agent for Acme Corp.
You have access to: `get_customer_record`, `get_transaction`,
`initiate_refund`, `escalate_to_human`.

When a user requests a refund:

1. Verify the account with `get_customer_record`
2. Retrieve the purchase details with `get_transaction`
3. If the purchase was within 30 days and its amout is less than $500, call `initiate_refund`
4. For amounts over $500, always escalate regardless of purchase date
5. If ineligible, call `escalate_to_human` and explain why

Never approve a refund without completing steps 1 and 2 first.

Compare this to the tool definition from the previous section. The tool schema said nothing about when to be called, what order to follow, or what to do when an amount exceeds a threshold. The skill encodes all of that:

Available tools: The skill names the specific tools relevant to this task, not everything the agent has access to.
Sequence and conditions: Steps 1–5 define the order and the branching logic.
Guard rails: "Never approve without completing steps 1 and 2" is judgment the tools themselves can't encode.

The tools handle execution. The skill handles when, in what order, and under what conditions.

The distinction from tools becomes clearest at the boundary between capability and judgment. A tool knows how to execute a database query. A skill knows when a query is the right mechanism versus, say, asking a user for clarification first. That's the bridge skills provide: from what an AI can do to what it should do in a given scenario.

Key Differences at a Glance

The distinction between tools, MCP servers, and skills lies in their architectural layer, scope, and security considerations:

Definition and scope: A tool is a fundamental capability, defined as a single, specific callable function that the model can invoke via its API schema. Above this is the MCP server, which acts as a standardized protocol server. It exposes a collection of capabilities, including actions, data, and prompts, which are used by AI clients via the MCP protocol. The highest layer is the skill, which is not a capability but a set of instructions guiding AI behavior toward a complex goal, managing a multi-step workflow or domain reasoning through the agent's orchestration layer.
Coupling and portability: Another key difference is portability. Tools are tightly coupled to the application they are defined within. In contrast, MCP servers are portable, designed to work across any compliant client, making them a universal connector. Skills are specific to the particular task or domain they are designed for.
Security surface: Each layer presents a distinct security surface. Security for tools focuses on function-level permissions. MCP servers manage risk through protocol-level consent and capability negotiation. Skills introduce behavioral guardrails and decision boundaries, controlling the overall logic and sequence of actions to ensure appropriate conduct.

The following picture summarizes these distinctions:

The relationship is hierarchical: skills direct what to accomplish, tools do the work, and MCP servers are the infrastructure that makes tools available consistently. None of the three replaces the others.

A Security Perspective

Each layer introduces distinct security considerations, and they compound when combined.

At the tool layer, the core risk is over-permission. A tool that can read and write to a database, when the AI only needs to read, creates unnecessary exposure. Prompt injection attacks (where malicious content in retrieved data tricks a model into taking unintended actions) are most damaging when tools have broad permissions. The principle of least privilege applies here as directly as it does anywhere in security engineering.

At the MCP server layer, the attack surface expands because MCP servers are external processes, often network-accessible, and connected to by multiple clients. The risks here include:

Tool poisoning: A malicious or compromised server exposes functions that look legitimate but behave maliciously when called.
Unauthorized access: Without proper authentication, any client could invoke a server's capabilities, including sensitive ones.
Scope creep: Servers that expose more than intended, by design or misconfiguration, give connected clients broader access than warranted.

The MCP specification addresses this through explicit consent requirements and capability negotiation, but correct implementation is the server author's responsibility. Remote MCP servers should require OAuth 2.1-based authentication, and permissions granted to any connection should follow the least-privilege principle.

To mitigate risks in both tools and MCP servers, apply the following:

Strict Scoping: Never give an AI tool a "God Mode" API key. Use scoped tokens that only allow the specific actions required for that tool.
Human-in-the-Loop: For high-stakes tools (like making a payment or deleting data), always require an approval from the user before the application executes the model's tool call.
Input Validation: Treat every argument generated by an LLM as untrusted user input. Validate the types, ranges, and permissions before hitting your backend.

At the skills layer, the risks become behavioral. Skills that don't account for adversarial inputs, that allow irreversible actions without human confirmation, or that chain too many autonomous steps without a checkpoint are dangerous in a specific way. By the time someone can intervene, the damage is done.

Auth0 for AI Agents addresses several of these challenges at the identity layer. Based on standards, it provides support for user authentication, delegation patterns for acting on a user's behalf, and asynchronous authorization for scenarios where sensitive operations need human sign-off before proceeding. Auth0's MCP support, now generally available, provides OAuth 2.1-based authentication for MCP servers.

The underlying principle is familiar from traditional IAM: identity infrastructure doesn't fundamentally change because the client is an AI, but the patterns for applying it need to account for how agentic systems behave differently.

Three Layers, One System

The shift from AI as a generator to AI as an actor is real, and the architecture that supports it is becoming clearer:

Tools give AI a way to act on the world.
MCP servers give it a consistent, portable way to access those actions.
Skills give it the reasoning framework to act appropriately.

Each layer has its own design considerations, its own security surface, and its own place in a well-structured AI system. Understanding the distinctions is foundational to building systems that aren't just capable, but trustworthy. As the tooling matures, the teams that understand the layers will be the ones building systems they can actually reason about.

For a closer look at the vulnerabilities that emerge in agentic AI, five critical AI agent security risks is a practical next step. If you're working through identity for MCP servers specifically, the Auth0 AI documentation covers authentication, delegation, and human-in-the-loop authorization patterns.

AI Agents Have Two Souls. You Only Control One

Andrea Chiarelli — Fri, 08 May 2026 16:04:16 +0000

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

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

Looking for an AI Agent Definition

Beyond the generic definitions that emphasize the level of autonomy in making decisions, I'd like to point out a slightly more technical one that I prefer. It comes from Microsoft and seems to be quite consistent with the OWASP definition:

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

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

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

We can visualize this definition into the following diagram:

Aside from input, output, and external resources, the heart of an AI agent is a collection of instructions, the LLM, and the Agent Core.

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

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

Looking at the diagram, we notice two interesting things:

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

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

The Two Souls of an AI Agent

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

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

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

Saying that LLMs are not deterministic is not the same as saying it is non-deterministic. While commonly LLMs are considered to be non-deterministic, this is not correct in computational terms. See this article to learn why LLMs are not non-deterministic.

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

If you are a philosophy enthusiast, you might notice a certain reference to the dualities of the human soul: from Plato's myth of the winged chariot to St. Augustine's two wills to Nietzsche's distinction between the Apollonian and Dionysian concepts.

The tension is the same: one controlled, one wild. And the wild one gets all the attention.

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

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

The Three Laws of AI Security Applied

Some time ago, I wrote an article about the three laws of AI security. Paraphrasing Asimov's three laws of robotics, I defined similar laws to control the less deterministic part of AI. Similar to what I have analyzed in this article, I observed that the fundamental problem in building secure AI-powered applications is the loss of that control we have become accustomed to with deterministic software.

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

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

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

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

The Data Control Law

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

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

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

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

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

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

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

The Command Control Law

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

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

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

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

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

To give your agent only the permissions it needs, use scopes in your access tokens and apply the principle of least privilege.

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

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

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

The Decision Control Law

The third law is about decision control and says:

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

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

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

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

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

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

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

Your Takeaways for Securing AI Agents

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

Here are the main takeaways that I want to highlight:

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

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

Manage Your Auth0 Tenants Faster with the Gemini CLI Extension

Jessica Temporal — Wed, 29 Apr 2026 21:01:35 +0000

Stop switching between your browser and terminal to manage identity. In this video, I'll show you how to integrate the Auth0 MCP Server directly into your Gemini CLI.

Learn how to leverage AI to query your applications, initialize tenants, and manage APIs using natural language commands without leaving your development environment.

What You'll Learn

How to find the Auth0 extension on the official Gemini page.
The one-command installation process for the Auth0 MCP server.
Authenticating and initializing your Auth0 environment via CLI.
Using natural language to list applications and create new API resources.

Resources

Things Developers Get Wrong About the Backend for Frontend Pattern

Andrea Chiarelli — Fri, 24 Apr 2026 15:51:18 +0000

Since I published my overview of the Backend for Frontend (BFF) pattern, the questions I've received fall into surprisingly consistent patterns. The same misunderstandings come up again and again, from developers who genuinely want to build secure apps.

Most of these misconceptions aren't just academic. They lead teams to ship apps with real security gaps while believing they've done the right thing. Let me address the ones I see most often.

Why PKCE Isn't a Replacement for BFF

This is the one I encounter most, and it's the most consequential.

The OAuth working group deprecated the Implicit Grant for SPAs and recommended Authorization Code with PKCE as the replacement. That guidance is correct. In addition, OAuth 2.1 recommends PKCE for any client, not just SPAs. Somehow, many developers concluded that PKCE also addresses token storage security. It doesn't.

PKCE (Proof Key for Code Exchange) protects the authorization code in transit. It prevents an attacker who intercepts the authorization code from exchanging it for tokens. Valuable, but it solves only one step of the OAuth flow.

Once your app receives tokens, PKCE has done its job. It has nothing to say about where those tokens live in the browser or what happens if a Cross-Site Scripting (XSS) attack runs in your app's context. Tokens in localStorage, sessionStorage, or even JavaScript memory are all reachable by malicious scripts.

BFF solves a different problem: it keeps tokens out of the browser entirely. The BFF exchanges the authorization code for tokens and stores them server-side. The browser gets an HttpOnly session cookie. An XSS attack running in that browser can't steal what isn't there.

PKCE and BFF are complementary, not alternatives. If your threat model includes XSS (and for most apps, it should), PKCE alone isn't enough.

BFF Is Not Just a Proxy

In a couple of cases, I've reviewed architectures labeled as "BFF" that were actually reverse proxies forwarding requests (and tokens) to a backend. That's not a BFF.

The defining characteristic of a Backend for Frontend is that it acts as a confidential OAuth client. It holds a client secret. It handles the full OAuth flow, including token exchange. Most critically, tokens never leave the server.

A reverse proxy that forwards an Authorization header containing a bearer token is not a BFF. The token is still accessible to the browser. You've added a network hop without the security benefit.

The IETF OAuth 2.0 for Browser-Based Apps BCP actually distinguishes between a Token-Mediating Backend (a backend that obtains tokens and then forwards them to the frontend) and a proper BFF (where tokens are never passed to the frontend at all). These are different patterns with different security properties.

If your backend is passing tokens to the browser in any form, you haven't implemented BFF. You've implemented token mediation, which is better than nothing, but it's not the same thing.

No, Cookies Are Not Less Secure Than Tokens

This one has roots in a legitimate historical concern. Cookies have a complicated reputation: they've been misused, and Cross-Site Request Forgery (CSRF) attacks were a real problem before SameSite became standard. Some of the "don't use cookies" instinct also came from REST API orthodoxy, where stateless communication was treated as a design virtue.

But here's what modern reality looks like: an HttpOnly session cookie cannot be read by JavaScript. That means XSS attacks can't steal it directly. A JWT in localStorage can be read by any script running on your page.

The attack surface isn't symmetric. A CSRF attack using an HttpOnly cookie requires the attacker to trick a user into making a specific authenticated request from another origin. An XSS attack that steals a localStorage token gives the attacker full, direct access to call any API as that user, from anywhere, without any user interaction required.

With SameSite=Strict or SameSite=Lax, CSRF attacks against HttpOnly cookies are already difficult in most real-world scenarios. Add explicit CSRF tokens and they become practically infeasible.

HttpOnly cookies aren't immune to CSRF, but the attack surface is far smaller than XSS-based token theft. You're trading one attack vector (XSS-based token theft) for a different, more constrained one (CSRF). That trade is almost always worth making.

BFF Does Not Solve All Your Browser Auth Security Problems

BFF shifts the security boundary. It doesn't eliminate it.

When you adopt BFF, you trade the token theft problem (XSS can steal tokens from browser storage) for the session management problem (your BFF now manages sessions and those need to be secured properly). This is a good trade in most cases, but it comes with responsibilities that BFF doesn't automatically fulfill.

Things BFF does not handle on its own:

CSRF protection. Your BFF uses cookies, which means state-changing requests need CSRF protection. SameSite cookies help significantly, but this is still your responsibility to configure correctly.
Session invalidation. When a user logs out, you need to revoke the session server-side, not just clear the cookie client-side. If you don't, stolen session cookies remain valid until natural expiry.
Secure cookie configuration. Secure, HttpOnly, and the right SameSite setting are all required. Missing any of them weakens the pattern's security properties.
Authorization checks in your API. BFF protects the token in transit. It doesn't automatically secure your API endpoints. You still need proper authorization logic on the backend.

Don’t implement BFF and then relax your overall security posture, assuming the pattern covers everything. It doesn't. Treat it as one layer in a defense-in-depth approach.

You Don’t Need to Rewrite Your Entire Application

The assumption that teams must rewrite the entire application prevents them from adopting BFF even when they should.

The full vision of BFF, as Sam Newman originally described it, is a server tailored to the specific needs of one frontend. That can mean a significant rearchitecting effort. But you don't have to implement the full pattern at once to get the security benefits.

In practice, many teams introduce BFF incrementally. The most common path:

Add a lightweight backend (Node.js, Next.js server components, ASP.NET Core, Python, or whatever fits your stack) that handles the OAuth flow.
The BFF exchanges authorization codes for tokens, stores them server-side, and issues session cookies to the browser.
Your existing frontend continues making API calls, now using session cookies instead of bearer tokens.

Your existing backend APIs often don't change at all. You're inserting the BFF as the authentication layer, not replacing your entire architecture.

The incremental path is real, and the auth-focused version of BFF is where most of the security value lives anyway.

Start With the Threat Model

Before deciding whether to implement BFF, be honest about your app's threat model.

If your application handles sensitive data, if XSS is a credible risk (and it usually is, especially for apps loading third-party scripts or rendering user-generated content), or if you operate in a regulated industry, BFF is the right choice. The complexity cost is manageable and the security benefit is concrete.

If you're building a simple public-facing app with no sensitive user data and strong existing XSS defenses, a well-implemented SPA with PKCE and in-memory token storage may be acceptable.

The BFF pattern exists because the browser is a hostile environment for tokens. If that threat is real for your application (and you're the best judge of that) BFF addresses it in ways that PKCE and in-browser token handling simply can't.

From Backend Engineer to Building AI Infrastructure at a Startup

Carla Urrea Stabile — Wed, 22 Apr 2026 16:05:00 +0000

What does it look like to go from a six-person startup team to running the infrastructure behind 1,000+ AI models?

Matteo and I have known each other for over 10 years, but I realized I'd never actually asked him about his engineering journey in depth. I knew he was doing infrastructure work, but I didn't know the full story of how he got there. This conversation filled in a lot of gaps for me.

In Episode 4 of Making Software, I talked to Matteo Ferrando, Platform and Infra Engineer at fal.ai, about exactly that.

What we covered

The pivot that changed everything. The company didn't start as an AI company. Matteo talks about what the original product was, how the pivot happened, and why letting go of something that's working is one of the hardest things you'll do at a startup as an engineer.
How a backend engineer ends up doing infra. There was no "switch." Matteo explains the reality of early-stage startups where in the beginning, there's no database, no Kubernetes cluster, no nothing. You just build it.
A decision-making framework worth stealing. One-way doors vs. two-way doors. Simple concept, but it changes how you think about MVPs, technical debt, and when to actually invest in doing things "the right way."
Optimizing a routing layer from 100ms to 5ms. The use case that forced this is wild. I'll let Matteo tell that story.
Do you still need computer science fundamentals? We talked about AI coding tools, what they're great at, and a very specific failure mode that Matteo keeps seeing on his team.

A couple of things Matteo said that stuck with me

"I'm not obsessed about technical debt like many engineers are. It's fine to have technical debt and we'll get to it."

This resonated a lot with me. I think a lot of us carry guilt about tech debt like it's something we did wrong. Matteo's framing is different: it's not a problem until it's actually a problem. That shift in perspective is freeing.

"A mistake introduced by an AI that you prompted is still your mistake. You still have to understand what you're shipping."

This one hit. Especially right now, when so many of us are leaning on AI tools to write code faster. Faster is great, but Matteo makes a really compelling case for why "I didn't write it" is not an excuse. He shares a specific example from his team that I think every developer using AI tools needs to hear.

Final thoughts

Talking to Matteo reminded me that there's no clean, linear path in engineering. You don't go from "backend engineer" to "infra engineer" because you planned it. You get there because something needs to exist and you're the one who builds it. I think that's something a lot of us can relate to, especially if you've ever worked at a startup.

Have you ever had to build something way outside your comfort zone because no one else was going to? Let me know in the comments!

Listen to the full episode

Available on YouTube, Apple Podcasts, and Spotify.

Thanks for reading! 👋

How to Use Auth0 Agent Skills in Claude Code & AI Coding Assistants

Jessica Temporal — Mon, 06 Apr 2026 18:27:59 +0000

Tired of your AI coding assistant hallucinating APIs or writing insecure auth patterns? In this video, I'll show you how to use Auth0 Agent Skills to teach your AI assistant (like Claude Code or GitHub Copilot) how to implement Auth0 correctly. Say goodbye to XSS vulnerabilities and manual JWT decoding—ship production-ready, secure authentication from the start.

What You'll Learn

Why standard AI coding assistants struggle with secure authentication.
How to install Auth0 Agent Skills via NPX or Claude Code plugins.
The difference between Core Skills and SDK Skills (React, Next.js, etc.).
A side-by-side comparison of "hallucinated" code vs. secure Auth0 patterns.
How to implement production-ready auth in Next.js using Agent Skills.

Resources

📝 Read the full blog post
🛠️ Auth0 Documentation
💻 GitHub Repo

Auth0 MCP Server Extension for Gemini CLI

Jessica Temporal — Fri, 27 Mar 2026 11:00:00 +0000

The Auth0 MCP Server is now listed on the official Gemini CLI extensions page. This means the Auth0 MCP Server is now directly installable through Gemini CLI with one command, allowing you to authenticate to Auth0 directly from your Gemini CLI session and load tenant information automatically.

What the Auth0 MCP Server Extension Provides

The extension packages the Auth0 MCP Server for Gemini CLI and adds three integration layers:

Discoverability: Listed on geminicli.com/extensions, searchable by name, installable without manual configuration.

Authentication Commands: Built-in slash commands for Auth0 tenant management:

/auth0:init - Device authorization flow with tenant selection
/auth0:logout - Session termination
/auth0:session - Current authentication status

Context Injection: After authentication, Gemini gains your tenant information so the AI can query applications, APIs, connections, actions, and logs without requiring manual tenant specification in every prompt.

Installation and Setup

Install the extension:

gemini extensions install https://github.com/auth0/auth0-mcp-server

Once the command successfully finishes you should see a message stating Extension “Auth0” installed successfully:

Initialize the Auth0 MCP Server:

/auth0:init

Make sure to allow the command to run when prompted. The server will run automatically.

You'll authenticate via device code flow to select your tenant:

And confirm the permissions:

Once authenticated, you should see a message within Gemini saying the Auth0 MCP Server is configured and to restart Gemini CLI to see the changes:

Refresh the MCP server list with the following command:

/mcp refresh

Gemini now has Auth0 context. Ask: "show me my applications" and the AI will receive the structured information about your applications, which Gemini CLI will display as a structured tool call result:

And since Gemini now understands your tenant structure, existing configurations, and naming conventions, it can also show you the same information in a more readable format:

Why This Matters

Before this extension, using the Auth0 MCP Server with Gemini CLI required manual server configuration, environment variable setup, and custom initialization scripts. The extension collapses that into a single install command and three slash commands.

More importantly: context persistence. Once authenticated, every Gemini session knows your Auth0 environment. You're not re-explaining your tenant structure or copy-pasting app IDs. The AI assistant operates with the same tenant awareness you have.

This is the same Auth0 MCP Server that powers VS Code integrations, now packaged for Gemini CLI's extension model. Same capabilities, different CLI.

What's Next

The Auth0 MCP Server supports tenant management, application configuration, API setup, and log analysis. For implementation details and the full MCP Server feature set, see the list on GitHub here.

The extension is available now at geminicli.com/extensions. Install, authenticate, and start managing Auth0 tenants through natural language.

The Future of Coding is Communication, Not Just Code

Carla Urrea Stabile — Thu, 26 Mar 2026 14:31:00 +0000

We recently had a great conversation on the Making Software podcast with Bobby Tierney. Bobby is a Principal Architect at Okta and Auth0 who focuses on agentic security, AI governance, and the Model Context Protocol (MCP).
I have been feeling some "AI FOMO" lately because the industry is moving so quickly. Talking to Bobby helped me bridge the gap between the "vibes" of modern AI coding and the security standards we need as professional engineers.

Vibe Coding vs. Mission Critical Production: Bobby shared his perspective on where "vibe coding" fits into the software development life cycle and when it becomes a risky proposition for an enterprise. He explained why prototypes are a great way to explore a solution space even if you eventually throw them away.
Managing "YOLO Mode" with Sandboxing: We discussed the "YOLO mode" found in many AI tools and how engineers can use progressive security configurations to keep things under control. -** The Shift to Spec-Driven Development:** Bobby talked about moving away from probabilistic guesswork and toward "spec coding". He explained how to use tools like "skills" or "slash commands" to align an AI with your team's specific DNA and ways of working.
The "Confused Deputy" Problem: We touched on the security risks of AI agents and why you shouldn't just give them machine credentials to act on a user's behalf. Bobby highlighted the importance of finding the right intersection between what a user is allowed to do and what the AI is permitted to do.
The Changing Role of the Engineer: We explored how AI is shrinking the development life cycle and why communication might be the most valuable skill for a developer in the future. Bobby also shared how designers and PMs are starting to use these tools to contribute directly to codebases.

Final Thoughts

Bobby reminded me that while tools are changing, the core of engineering is still about requirements and making good decisions.

The age of AI is not about replacing engineers. It is about helping them. By being good communicators, teachers, and security-minded builders, we can use these amazing tools to make better, safer software.

What is your take on YOLO mode coding? Let me know in the comments! 🌱
If you want to hear more, check out the full episode: https://listen.casted.us/public/49/Making-Software-2b1cff7b