Forem: Auth0

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

Common FAPI Misconceptions

Andrea Chiarelli — Fri, 20 Mar 2026 09:00:30 +0000

For some time now, I've been interested in FAPI from both an Identity practitioner's and a developer's perspective. I've written a few posts on this topic on the Auth0 blog and created a guide to FAPI with the support of colleagues who are much more experienced than I am. Surfing the web and talking to developers, however, I couldn't help but notice some misunderstandings about certain aspects of FAPI.

In this article, I'll summarize the most common and recurring ones.

Misconception 1: FAPI Is a New Protocol

FAPI is a security profile based on OAuth 2.1, it is not a new protocol, intended as an alternative to established standards like OAuth 2.0, SAML, or OpenID Connect (OIDC).

It acts as a prescriptive blueprint that defines exactly which OAuth 2.0 and OIDC extensions must be used and how they must be configured. While the core OAuth 2.0 specification (RFC 6749) is a flexible framework that provides a "toolbox" of flows and leaves security decisions to the implementer, FAPI removes this "dangerous flexibility" to ensure a secure-by-default posture.

Misconception 2: FAPI Is for Banks and Financial Organizations

The "F" in FAPI originally stood for "Financial," reflecting its initial goal to protect banking applications. However, the scope has expanded significantly. Today, FAPI is a general-purpose high-security profile for any industry handling sensitive, high-risk data. Major applications include:

E-Health: Protecting Patient Health Information (PHI) in standards like HL7 FHIR.
E-Signing: Securing the underlying API calls for legally binding digital signatures.
Government Services: Managing Personally Identifiable Information (PII) and government services.

Misconception 3: FAPI 2.0 Is an Incremental Update of FAPI 1.0

Some people mistakenly believe FAPI 2.0 is a minor version bump that maintains backward compatibility. This is incorrect. FAPI 2.0 is a complete redesign based on lessons learned from FAPI 1.0, specifically aimed at simplifying the developer experience.

A key change is the removal of the OpenID Connect Hybrid Flow used in FAPI 1.0 "Advanced," which required complex front-channel validations of ID Tokens. FAPI 2.0 replaces this with a hardened Authorization Code Flow where all tokens are delivered via the back-channel.

Misconception 4: OAuth 2.1 Makes FAPI Redundant

As OAuth 2.1 incorporates modern best practices like PKCE and the removal of the Implicit Flow, some wonder if FAPI 2.0 remains necessary. However, the difference between the two is significant.

OAuth 2.1 is a "Best Current Practice" consolidation for the general community, while FAPI 2.0 is a "high-security profile" that mandates features OAuth 2.1 only recommends. Crucially, FAPI 2.0 is built on a Formal Attacker Model, providing proof of security against specific threats that OAuth 2.1 does not formally address.

Misconception 5: You Can Use Any Type of Client with FAPI

Standard OAuth 2.0 allows for both public (e.g., mobile, browser-based) and confidential (server-side) clients. However, while FAPI 1.0 Baseline specification allows for public clients, FAPI 1.0 Advanced and FAPI 2.0 explicitly excludes support for them.

FAPI 2.0 focuses on confidential clients because they are capable of protecting a private key. This is the cornerstone of FAPI’s security model; a client cannot perform asymmetric authentication or prove possession of a sender-constrained token if it cannot keep its private key secure.

Misconception 6: You Can’t Use Public Clients with FAPI

As a consequence of the previous point, you may conclude that you can’t use public clients at all with FAPI. So, you can’t have mobile applications or SPAs in a FAPI-based system.

Actually, this is not entirely true. You can still have public clients in a FAPI context provided that they don’t manage ID and access tokens. For example, you can have a SPA if you are using an architectural pattern like the Backend for Frontend pattern.

Misconception 7: Pushed Authorization Requests Support Simply Shortens URLs

Developers often view Pushed Authorization Requests (PAR) as merely an optional optimization for long URLs. In reality, FAPI 2.0 makes PAR mandatory because it moves the entire authorization request from the risky environment of the browser to the secure back-channel.

Standard GET requests expose sensitive data (scopes, identifiers) to browser history, server logs, and Referer headers. PAR solves this by having the client POST parameters directly to the server, receiving an opaque request_uri in return. This ensures:

Confidentiality: Sensitive parameters are never in the URL.
Integrity: The server authenticates the request before the user is ever involved.
Reliability: It bypasses URL length limits that often break complex authorization requests.

Wrapping Up

The journey through the FAPI landscape often involves navigating a complex mix of technical details and outdated assumptions. As this article has shown, FAPI is far more than an obscure security framework for banks; it is a critical, mature security profile that strips away the risky flexibility of standard OAuth 2.0 to offer a secure foundation for any system handling high-value data.

From understanding that FAPI is a profile, not a new protocol, to recognizing the fundamental changes in FAPI 2.0 and its mandated use of features like Pushed Authorization Requests (PAR), a clear picture emerges. FAPI’s strict reliance on confidential clients and back-channel communications is a pragmatic response to known threat models, ensuring integrity and confidentiality where it matters most.

Embracing FAPI is not about adding unnecessary complexity. It is about adopting a proven security posture necessary for protecting assets in e-Health, e-Signing, government services, and beyond. By moving past these common misconceptions, organizations can leverage FAPI to build truly robust and compliant high-security applications.

Here is an infographic that summarizes the misconceptions discussed in this article. Keep it handy:

Demystifying OAuth Security: State vs. Nonce vs. PKCE

Jessica Temporal — Fri, 13 Mar 2026 16:17:44 +0000

Confused by the random strings in your OAuth URLs? You aren't alone. Many developers think state, nonce, and code_challenge (PKCE) are redundant—but skipping just one could leave your users' accounts wide open to attackers like "Eve." In this video, I'll break down why these three parameters are like three different locks on three different doors. We’ll look at real-world attack scenarios and show you exactly how each one keeps your app secure.

💡 What You’ll Learn:

The State Parameter: How to prevent Cross-Site Request Forgery ($CSRF$) attacks.
The Nonce Parameter: Why ID tokens need protection against Replay attacks.
PKCE (Proof Key for Code Exchange): Protecting mobile and single-page apps from Authorization Code Injection.
Implementation Strategy: Why you should use all three instead of picking just one.

🔗 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 👀

Secure a C# MCP Server with Auth0

Andrea Chiarelli — Fri, 13 Mar 2026 09:59:59 +0000

As the Model Context Protocol (MCP) gains traction, the transition from "localhost" experimentation to enterprise integration introduces a critical challenge: security. For developers building sophisticated integrations, treating every LLM request as an "admin" action is a significant risk.

Luckily, the MCP specification supports authorization based on OAuth 2.1. So, basically, to protect your MCP server, you have to treat it as a resource server with some extra challenges in case you want to share it publicly to a wide audience.

The .NET ecosystem can leverage the C# SDK for MCP to easily expose tools and resources to an AI-powered application. The SDK reached maturity recently supporting all the features defined by the specification, including security.

This article explores a practical implementation of a secured MCP server. You will walk through a sample project and learn how to:

Implement three distinct tools: one available for public consumption and two gated behind specific permission sets.
Make the protected MCP server available to an MCP client, such as VSCode, leveraging Dynamic Client Registration (DCR) supported by Auth0.

Why Protect an MCP Server?

In a standard local setup, the MCP server and the client often share the same security boundary. However, as soon as an MCP server is deployed as a shared service or connected to a multi-user LLM platform, that boundary shifts. Protecting the server becomes relevant for at least two reasons:

Preventing prompt injection escalation. If a tool allows an LLM to interact with internal databases or APIs, a malicious prompt could attempt to trick the model into executing commands it shouldn't. By implementing strict authorization checks at the server level, you provide a defense in depth strategy. Even if the LLM is convinced to call a restricted tool, the MCP server will reject the request because the underlying user context lacks the necessary permissions.
Resource isolation and multi-tenancy. Not every user interacting with an AI agent should have the same capabilities. For example, a junior developer might have access to a ReadDocumentation tool, but only a lead engineer should be able to trigger a DeployProduction tool. Without protection, the MCP server treats all requests as equal, which is unacceptable in any regulated or professional environment.

These reasons are what OAuth 2.1 support in the MCP specification aims to prevent. We will use it to protect a sample MCP server built with C# by integrating with Auth0.

To learn how Auth0 helps you secure MCP clients and servers, check out Auth for MCP. For a detailed explanation of authorization support in MCP, read the Authorization specification.

Build Your MCP Server in C

Let’s begin our exploration by implementing a very simple MCP server that we will later extend and secure using Auth0.

Prerequisites

The MCP server project we are going to implement requires the following:

.NET SDK 10 or later,
The C# SDK for MCP package,
An Auth0 account. If you don’t have it, sign up for free here.

Create the MCP Server

To create a simple MCP server, you can use the MCP server template project provided by Microsoft. Currently, the template is in preview, so you won’t find it in the builtin template set. You can download and install the package by running the following command in a terminal window:

dotnet new install Microsoft.McpServer.ProjectTemplates

Once you have downloaded the project template, you can create your MCP server project by running a command like the following:

dotnet new mcpserver -n AspNetCoreMcpServer -t remote

This command creates a new MCP server project named AspNetCoreMcpServer in a folder with the same name. The option -t remote specifies to create an MCP server based on HTTP transport, which leads to actually creating an ASP.NET Core application.

MCP servers can use stdio or HTTP as transport protocols. OAuth protection for MCP servers is only designed for HTTP-based MCP servers. See When Should You Use Authorization? for more information.

Explore the project

Let’s take a quick look at the project to understand its implementation.

Go to the project’s folder and open the Program.cs file. You should see the the following code:

//Program.cs

var builder = WebApplication.CreateBuilder(args);

// Add the MCP services: the transport to use (http) and the tools to register.
builder.Services
    .AddMcpServer()
    .WithHttpTransport()
    .WithTools<RandomNumberTools>();

var app = builder.Build();
app.MapMcp();

app.Run();

This is an ordinary .NET application that uses the MCP server service (AddMcpServer). This service uses the HTTP transport (WithHttpTransport) and exposes the tools implemented by the class RandomNumberTools (WithTools<RandomNumberTools>). The invocation of the MapMcp() method initializes the MCP server.

The C# SDK for MCP library takes charge of all the complexity of implementing the MCP protocol. You can stay focused on the tool implementation, which is pretty straightforward as well.

Open the RandomNumberTools.cs file in the Tools folder and take a look at the code:

//Tools/RandomNumberTools.cs

using System.ComponentModel;
using ModelContextProtocol.Server;

internal class RandomNumberTools
{
    [McpServerTool]
    [Description("Generates a random number between the specified minimum and maximum values.")]
    public int GetRandomNumber(
        [Description("Minimum value (inclusive)")] int min = 0,
        [Description("Maximum value (exclusive)")] int max = 100)
    {
        return Random.Shared.Next(min, max);
    }
}

You see a very simple class implementing the method GetRandomNumber(), which returns a random number within a range. The attribute McpServerTool marks the GetRandomNumber() method as an MCP tool. The Description attributes describe what the tool does and what its parameters mean, very important to let the LLM understand when and how to use it. In fact, clear descriptions of the tool's functionality help the LLM select the appropriate tool for a given task.

That’s all! Your MCP server is ready to run.

Test your MCP server

Since the MCP server we implemented is nothing more than an ASP.NET Core application, we can test it in several ways: you can use curl or the .http file automatically generated with the project. Or you can use the MCP Inspector.

We'll integrate our MCP server directly into an MCP client like VSCode. This will come in handy later when we implement some advanced features.

You can add your MCP server to VSCode by creating a .vscode folder in your project’s root folder, and adding an mcp.json file with the following JSON content:

//.vscode/mcp.json
{
  "servers": {
    "AspNetCoreMcpServer": {
      "url": "http://localhost:PORT",
      "type": "http"
    }
  },
  inputs": []
}

Make sure to replace the PORT placeholder with the port your MCP server listens to.

Look at alternative ways to add your MCP server to VSCode.

Once you have added your MCP server to VSCode, set its chat window to agent mode and ask to get a random number. You should be prompted to authorize the use of the tool as shown in the following screenshot:

After you authorize it, you will get a random number:

Cool! You have a new working MCP server in your VSCode instance!

Protect Your MCP Server

Now let's move on to the real focus of this article: protecting your MCP server from unauthorized access.

Define the tools to protect

Currently, anyone installing your MCP server can use its only tool, get_random_number. This tool is publicly accessible because there is no restriction on it. You will leave it so, but you will also add two new tools that will require some form of authorization.

Specifically, you will add a tool that gets the current state of a hypothetical system and another one that sets the state of this system. The system is fictitious, of course, but you can think of it as a kind of processor that can be found in different states.

To implement these tools, add a new file named SystemTools.cs to the Tools folder with the following code:

//Tools/SystemTools.cs

using System.ComponentModel;
using ModelContextProtocol.Server;

internal enum SystemState
{
    Ready,
    Waiting,
    Running,
    Stopped
}

internal class SystemTools
{
    private static readonly SystemState[] AllStates = Enum.GetValues<SystemState>();
    private static SystemState? _currentState;

    [McpServerTool]
    [Description("Returns the current state of the fictitious system. Possible states are: Ready, Waiting, Running, Stopped.")]
    public string GetSystemState()
    {
        _currentState ??= AllStates[Random.Shared.Next(AllStates.Length)];
        return _currentState.ToString()!;
    }

    [McpServerTool]
    [Description("Sets the current state of the fictitious system. Valid states are: Ready, Waiting, Running, Stopped.")]
    public string SetSystemState(
        [Description("The new state to set. Must be one of: Ready, Waiting, Running, Stopped.")] SystemState state)
    {
        _currentState = state;
        return $"System state set to '{_currentState}'.";
    }
}

You see that the tool GetSystemState() picks a random state the first time it is called and stores it into a private static variable, _currentState. Any subsequent call to the tool will return the value stored in that variable.

The tool SetSystemState() changes the value of the state stored in the _currentState variable.

You will protect these two new tools by requiring that the user has specific permissions to use each of them.

According to the MCP specification, your MCP server is nothing but a resource server in the context of OAuth, and VSCode is just an OAuth client. So actually all you are going to implement is a well-known scenario: you will use Auth0 as the authorization server, which will authenticate the user and provide the access token to the MCP client (VSCode) in order to access the tools exposed by your MCP server. The access token will include the required permissions to access the protected tools.

However, you may have a little concern now. You want to share your MCP server as a package that anyone can download and use in their VSCode instance. How can they register their VSCode instance with Auth0 as required for any OAuth client? Well, the MCP specification supports a few ways to do this. You will use Dynamic Client Registration (DCR), which allows an MCP client (VSCode) to self-register with the authorization server (Auth0). Be aware that DCR raises security concerns, as we will mention later.

Configure your Auth0 tenant

First of all, you need to configure Auth0 at the tenant level. In fact, you need to enable Dynamic Client Registration to allow MCP clients to register. You also need to enable Resource Parameter Compatibility Profile as required by the MCP specification.

Keep in mind that these are tenant level settings, which means they affect all the applications registered in that tenant.

To enable those settings, go to Settings on the left menu and then select the Advanced tab. Scroll down to the Settings section and enable the Dynamic Client Registration (DCR) and Resource Parameter Compatibility Profile toggles, as shown in the image below:

As mentioned before, you need to enable Dynamic Client Registration to allow VSCode to self-register with Auth0 the first time a user interacts with your MCP server. This allows any client to register with Auth0 with potential risks such as resource exhaustion or unauthorized access attempts. Read Register your MCP Client Application to learn more about the dangers of an open DCR endpoint and possible solutions.

Beyond the static registration of an MCP client, an alternative approach is based on Client ID Metadata Document (CIMD), a recent standard whose implementation is in progress.

In addition to the previous tenant-level settings, you also need to promote the connections the MCP clients will use to domain level. To this purpose, go to the Authentication menu item of your dashboard and select the connection to configure. For our current example, select the Username-Password-Authentication connection under Database, and scroll down until you see the setting Promote Connection to Domain Level. Enable it as shown below:

Great! You have prepared your Auth0 tenant for self-registrations of MCP clients.

Register your MCP Server

Now you need to register your MCP server.

As mentioned earlier, from the OAuth point of view, an MCP server is nothing but a resource server or API server. This means that you can register it with Auth0 as a standard API. The only requirement is to make sure to set your MCP server base URL as the audience. This is a requirement of the Protected Resource Metadata specification. So, in your case, if your MCP server listens to http://localhost:5678, use this URL as the audience.

Once you have created your API on the Auth0 dashboard, scroll down in the Settings tab to reach the Access Token Settings section. Here, select the RFC 9068 format as shown in the following picture:

Read the documentation to learn more about access token profiles.

Then scroll down more to the RBAC Settings section and enable both RBAC and Add Permissions in the Access Token:

These settings will include the user’s permissions in the access token so your MCP server will be able to make authorization decisions to let users access the tools.

Save the settings and go to the Permissions tab. Here you should add the tool:getsystemstate and tool:setsystemstate permissions as shown below:

Follow the instructions in this document to learn how to add permissions to an API.

Finally, go to the Application Access tab and select the Allow value for the application access policy for user access, as you can see in the picture below:

This setting allows any self-registered MCP client to access your MCP server on behalf of the user. To learn more about this setting, read the API Access Policy documentation.

Now your MCP server is configured on the Auth0 side.

Secure your MCP Server

Let's complete the MCP server protection by modifying the current code.

First, add an appsettings.json file with the current content:

//appsettings.json

{
  "Auth0": {
    "Domain": "YOUR_DOMAIN",
    "Audience": "YOUR_MCP_SERVER_BASE_URL"
  },
  "McpServer": {
    "BaseUrl": "YOUR_MCP_SERVER_BASE_URL"
  }
}

Replace YOUR_DOMAIN with your Auth0 tenant domain, and YOUR_MCP_SERVER_BASE_URL with the actual URL of your MCP server. Remember that YOUR_MCP_SERVER_BASE_URL must also correspond to the audience you registered in Auth0.

Now you will add support for the access token validation and protection on the two MCP tools you added to the initial project.

Install the middleware to manage JWT tokens with the following command:

dotnet package add Microsoft.AspNetCore.Authentication.JwtBearer

Replace the current content of the Program.cs file with the following code:

//Program.cs
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using ModelContextProtocol.AspNetCore.Authentication;

var builder = WebApplication.CreateBuilder(args);

var authority = $"https://{builder.Configuration["Auth0:Domain"]}/";
var audience = builder.Configuration["Auth0:Audience"];
var mcpServerBaseUrl = builder.Configuration["McpServer:BaseUrl"];

builder.Services.AddAuthentication(options =>
{
    options.DefaultChallengeScheme = McpAuthenticationDefaults.AuthenticationScheme;
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.Authority = authority;
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidAudience = audience,
        ValidIssuer = authority
    };

    options.Events = new JwtBearerEvents
    {
        OnTokenValidated = context =>
        {
            Console.WriteLine("Token validated successfully.");
            return Task.CompletedTask;
        },
        OnAuthenticationFailed = context =>
        {
            Console.WriteLine($"Authentication failed: {context.Exception.Message}");
            return Task.CompletedTask;
        }
    };
})
.AddMcp(options =>
{
    options.ResourceMetadata = new()
    {
        Resource = mcpServerBaseUrl ?? audience ?? string.Empty,
        AuthorizationServers = { authority },
        ScopesSupported = ["tool:getsystemstate", "tool:setsystemstate"],
    };
});

builder.Services.AddAuthorization();

builder.Services
    .AddMcpServer()
    .WithHttpTransport()
    .AddAuthorizationFilters()
    .WithTools<RandomNumberTools>();

var app = builder.Build();

app.MapMcp().RequireAuthorization();

app.Run(mcpServerBaseUrl);

Let’s break down this code to understand what it does.

Basically, it adds support for authenticating client requests as in any ordinary ASP.NET Core Web API:

//Program.cs

//...existing code...

builder.Services.AddAuthentication(options =>
{
    options.DefaultChallengeScheme = McpAuthenticationDefaults.AuthenticationScheme;
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.Authority = authority;
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidAudience = audience,
        ValidIssuer = authority
    };

    options.Events = new JwtBearerEvents
    {
        OnTokenValidated = context =>
        {
            Console.WriteLine("Token validated successfully.");
            return Task.CompletedTask;
        },
        OnAuthenticationFailed = context =>
        {
            Console.WriteLine($"Authentication failed: {context.Exception.Message}");
            return Task.CompletedTask;
        }
    };
})

//...existing code...

This code sets up the access token validation logic through AddJwtBearer(). The OnTokenValidated and OnAuthenticationFailed event managers do nothing special apart from showing their message to the console, but you can use them for any customization you may need.

Just after AddJwtBearer() invocation, you find AddMcp(), as highlighted below:

//Program.cs

//...existing code...

builder.Services.AddAuthentication(options =>
{
  //...existing code...
})
.AddJwtBearer(options =>
{
  //...existing code...
})
.AddMcp(options =>
{
    options.ResourceMetadata = new()
    {
        Resource = mcpServerBaseUrl ?? audience ?? string.Empty,
        AuthorizationServers = { authority },
        ScopesSupported = ["tool:getsystemstate", "tool:setsystemstate"],
    };
});

//...existing code

The AddMcp() method defines the Protected Resource Metadata (PRM) document for this MCP server. This document provides useful information for the client about the capabilities of the MCP server and which authorization server to contact to access protected tools.

This document will be dynamically exposed at the URL YOUR_MCP_SERVER_BASE_URL/.well-known/oauth-protected-resource, where YOUR_MCP_SERVER_BASE_URL is the base URL of your MCP server. The document will contain the following JSON:

{
  "resource": "YOUR_MCP_SERVER_BASE_URL",
  "authorization_servers": [
    "https://YOUR_DOMAIN"
  ],
  "bearer_methods_supported": [
    "header"
  ],
  "scopes_supported": [
    "tool:getsystemstate",
    "tool:setsystemstate"
  ]
}

Finally, enforce authorization with the code highlighted below:

//Program.cs

//...existing code...

builder.Services.AddAuthorization();  //👈 new code

builder.Services
    .AddMcpServer()
    .WithHttpTransport()
    .AddAuthorizationFilters()  //👈 new code
    .WithTools<RandomNumberTools>();

var app = builder.Build();

app.MapMcp().RequireAuthorization();  //👈 changed code

app.Run(mcpServerBaseUrl);  //👈 changed code

You added the authorization middleware service (AddAuthorization()) and support for authorization filters (AddAuthorizationFilters()). Also, you applied authorization to the MCP endpoints (RequireAuthorization()) and forced the server to use the base URL defined in the appsettings.json file. The last change is not strictly required, but it ensures that you have one source of truth for the MCP base URL.

Add authorization policy

You added a generic support for authorization with AddAuthorization(). This makes sure that only authenticated users access the protected tools. But our initial intent is to allow users to access each specific tool based on their permissions.

You can do this by defining a couple of authorization policies based on the existence of specific permissions in the access token. To this purpose, replace the AddAuthorization() invocation with the following code:

//Program.cs

//...existing code...

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("GetSystemStatePolicy", policy =>
        policy.RequireClaim("permissions", "tool:getsystemstate"));

    options.AddPolicy("SetSystemStatePolicy", policy =>
        policy.RequireClaim("permissions", "tool:setsystemstate"));
});

//...existing code...

This code defines two authorization policies:

GetSystemStatePolicy based on the tool:getsystemstate value for the claim permissions.
SetSystemStatePolicy based on the tool:setsystemstate value for the claim permissions.

Let’s complete the protection of the tools by applying the authorization filter with the specific policy, as shown below:

//Tools/SystemTools.cs

//...existing code...

internal class SystemTools
{
    //...existing code...

    [McpServerTool]
    [Description("Returns the current state of the fictitious system. Possible states are: Ready, Waiting, Running, Stopped.")]
    [Authorize(Policy = "GetSystemStatePolicy")]  //👈 new code
    public string GetSystemState()
    {
        //...existing code...
    }

    [McpServerTool]
    [Description("Sets the current state of the fictitious system. Valid states are: Ready, Waiting, Running, Stopped.")]
    [Authorize(Policy = "SetSystemStatePolicy")]  //👈 new code
    public string SetSystemState(
        [Description("The new state to set. Must be one of: Ready, Waiting, Running, Stopped.")] SystemState state)
    {
        //...existing code...
    }
}

Your MCP server is secure now!

Test Your Secure MCP Server

Now it’s time to test your brand new secure MCP server!

Run your server with the dotnet run command.

Then, in your VSCode instance, restart your MCP server:

After a few seconds, you will see a popup message like the following:

This message is the effect of the RequireAuthorization() execution you added to the server. It sent a 401 HTTP status message to VSCode with a reference to the Protected Resource Metadata document, where VSCode found all the needed info to start the user authentication and authorization process.

Once you have allowed the authentication flow, you will get the authorization request that VSCode is about to send to Auth0, as shown below:

After user authentication, you will be requested to authorize VSCode to access your profile:

Once you accept the request, you will be redirected back to your VSCode instance.

You didn’t notice it, but under the hood, your VSCode instance automatically registered with Auth0 using DCR. You can verify this by going to your Auth0 dashboard and look in the list of the registered applications. You will see VSCode among them, and it is marked as a third-party application, as you can see below:

Now your VSCode instance has an access token to access the tools implemented by your MCP server.

Make sure your chat window is in Agent mode and list the tools provided by your MCP server. You will see only the get_random_number tool:

Why? Doesn’t VSCode have an access token?

VSCode has an access token, but without the required permissions to access the protected tools. So you can only access the public tool as before the protection implementation.

To test your MCP server properly, you should assign one or more of the required permissions to your user profile on Auth0. Follow the instructions in Assign Permissions to Users to assign the tool:getsystemstate permission to your user profile.

Use the command palette to sign out and restart your MCP server in VSCode. Then authenticate and check again the list of tools available to you. This time you should also see the get_system_state tool:

Ask something involving the state of the fictitious system in the chat window, as shown in the following screenshot:

You should be able to use the tool as expected.

Now, feel free to play with the permissions to get access to the other tool.

Let’s Recap

After a long journey, this article provided a comprehensive guide on securing a C# MCP server using Auth0, transforming it from a local experiment into an enterprise-ready resource server.

The journey covered the following main steps:

Building the Base MCP Server: You quickly set up a basic, unsecured MCP server using the C# SDK for MCP and the MCP server template, exposing a simple GetRandomNumber() tool.
Defining Protected Tools: You introduced two new tools, GetSystemState() and SetSystemState(), which require specific authorization, setting the stage for security implementation.
Auth0 Tenant Configuration: You configured the Auth0 tenant by enabling Dynamic Client Registration (DCR) to allow MCP clients (like VSCode) to self-register, and enabling the Resource Parameter Compatibility Profile as required by the MCP specification. We also promoted necessary connections to the domain level.
Registering the MCP Server as an API: The MCP server was registered with Auth0 as a standard API (Resource Server), ensuring its base URL was set as the audience. You configured it to use RFC 9068 access tokens and enabled Role-Based Access Control (RBAC) to include permissions in the access token.
Securing the Server Code: You updated the C# application to:
- Include necessary configuration via appsettings.json.
- Integrate the JwtBearer authentication middleware for access token validation against Auth0.
- Define the Protected Resource Metadata (PRM) document using AddMcp(), providing clients with authorization server and scope information.
- Implement authorization policies based on specific permissions.
- Apply these policies to the respective tools using the [Authorize] attribute.
Testing the Secure Server: Finally, you tested the secured server by integrating it with VSCode. The process demonstrated the DCR flow, user authentication, and the crucial step of assigning user permissions within Auth0 to grant access to the newly protected tools.

By following these steps, you successfully implemented an OAuth 2.1-compliant security layer, ensuring that access to sensitive tools is gated by proper user permissions validated through Auth0.

You can download the final version of this project from this GitHub repository, looking into the auth-for-mcp/aspnetcore-mcp-server folder.

To learn more about using Auth0 to secure your AI agents check out Auth0 for AI Agents.

The four-year-old typo that nobody can fix 🧟 and more about building developer tools

Carla Urrea Stabile — Wed, 25 Feb 2026 14:30:00 +0000

As the host of Making Software I get to have some pretty real conversations about what it actually takes to build good software. And in my recent chat with Raghd Hamzeh (Senior Software Engineer at Okta and a core maintainer of OpenFGA) hit home for me.

We talked about a side of engineering that doesn’t get enough airtime: what happens when your users are other engineers? If you’ve ever built an API, an SDK, or even just a shared library, you know that developers are the most rewarding, but also the most "vocal" audience you can have.

Here are the three things from our conversation that have been living rent-free in my head:

1. The "Breaking Change" Itch is Real 😬

Raghd admitted something that I think a lot of us can relate to: when there’s a four-year-old typo in one of the products you're building, that drives you crazy. It could be just a small naming inconsistency, but when it’s there, it's staring back at you every time.

We got into that internal battle every maintainer knows: do you break everyone’s build just to satisfy the need for a clean API? Probably not. But it’s a powerful reminder that the decisions we make in Month 1, like how we pass a parameter, become the legacy we have to live with in Year 5.

2. Stop building "Alien" SDKs 👽

This one got personal! While coding on the Ruby SDK for OpenFGA, I ran into this head-on. Rubyists are opinionated (I should know, I’m one of them).

When you’re building multi-language tools, you’re constantly balancing two things:

Consistency: Making sure the Go SDK and the Python SDK behave the same way.
Idiom: Making sure a Ruby dev doesn't feel like they're writing Java code with extra steps.

Raghd’s take? You won't get it perfect 100% of the time. Sometimes, you have to prioritize the long-term health of the platform over a "perfectly idiomatic" implementation just so the project stays maintainable for the team behind it. That tension never fully goes away, you just get better at navigating it.

3. The "AI" file that’s actually for humans 🤖

With the rise of AI, everyone is adding agents.md files to their repos. Raghd had a spicy take: Write that file for your human contributors first.

If you want people to help you build your open-source dream, lay out your expectations clearly:

How should commits be structured?
What does the core architecture look like?
Should contributors open an issue before submitting a PR?

Documenting these "non-code" decisions up front saves an enormous amount of friction. It turns "This PR isn't what we wanted" into "Here is the blueprint we’re all following."

🎙️ Want the full story?

Check out the full episode of Making Software here: Link to episode

I’d love to hear from you in the comments, what’s the one tiny thing in your codebase that you’re dying to "breaking change" just to feel better? 😅

Strengthening OAuth 2.0 with FAPI 2.0

Andrea Chiarelli — Tue, 24 Feb 2026 08:27:26 +0000

OAuth 2.0 has long been the cornerstone of modern authorization. It is a consolidated technology that powers everything from social logins to complex enterprise integrations. Developers appreciate its flexibility, which allows them to adapt the framework to various scenarios like traditional web applications, single page applications, desktop and mobile environments.

However, this flexibility is a double-edged sword. Because OAuth 2.0 is a framework rather than a rigid protocol, it provides a collection of specifications that developers can combine in different ways. In high-risk and regulated sectors like banking, healthcare, and insurance, this freedom creates a significant surface area for configuration errors and interoperability issues. This is where the FAPI profile steps in, providing a strict set of rules to ensure the highest levels of security and trust.

The Flexibility Paradox of OAuth 2.0

The fundamental challenge with "vanilla" OAuth 2.0 is the vast number of optional features. While the core specification defines the basic grant types, it leaves many security decisions to the implementer. For a developer building a low-risk internal tool, these choices are manageable. But for an architect designing a system for Open Banking or sensitive patient records, the stakes are much higher.

In high-assurance environments, the phrase "with great power comes great responsibility" applies literally. Security vulnerabilities often arise not from flaws in the individual specifications, but from how they are combined. For example, a system might use the Authorization Code Flow but fail to implement Proof Key for Code Exchange (PKCE) or use insecure redirect URIs. FAPI 2.0 solves this by removing the "optional" from security best practices and mandating a "secure by default" posture.

What Is FAPI 2.0?

FAPI 2.0 is a security profile developed by the OpenID Foundation. Unlike its predecessor (FAPI 1.0), which was often criticized for its complexity, FAPI 2.0 focuses on simplicity and robust interoperability. It is not a new protocol. Instead, it is a prescriptive profile that defines exactly which OAuth 2.0 and OpenID Connect extensions must be used and how they must be configured.

The profile is built upon a formal attacker model that assumes a high-threat environment where attackers might control the network or have the ability to intercept front-channel messages. By adhering to FAPI 2.0, organizations ensure their authorization servers and clients meet a standardized level of resistance against modern attack vectors like session injection, token theft, and authorization request tampering.

Hardening OAuth 2.0

The key security enhancements introduced by FAPI 2.0 to strengthen the OAuth 2.0 framework focus on three main areas: hardening the authorization request, eliminating bearer token risks, and improving client authentication. Here are the most relevant protection mechanisms FAPI 2.0 enforces:

Pushed Authorization Requests (PAR): FAPI 2.0 mandates PAR to mitigate the risks of sending sensitive authorization parameters (like scopes and PKCE challenges) over the insecure front-channel (browser). With PAR, the client sends these parameters via a secure back-channel POST request before redirection. The server then issues a short-lived request_uri used in the subsequent browser redirect, ensuring sensitive data never appears in browser history or logs.
Sender-Constrained Tokens: FAPI 2.0 moves away from vulnerable bearer tokens by enforcing "sender-constrained" tokens, which are cryptographically bound to the client that requested them. This prevents token misuse even if stolen. The primary mechanisms for this are Mutual TLS (mTLS), which binds the token to the client's X.509 certificate, and Demonstration of Proof-of-Possession (DPoP), a more flexible, application-level solution where the client proves possession of a private key using a signed JWT with every request.
Asymmetric Client Authentication: FAPI 2.0 replaces shared client secrets with asymmetric authentication, typically using Private Key JWT. The client signs a JWT with its private key, which the authorization server verifies with the client's registered public key. This method removes the risk of client secrets being leaked during transmission.

The Role of FAPI Certification

A critical component of the FAPI ecosystem is the OpenID Foundation's certification program. Because security depends on correct implementation, the foundation provides a suite of automated tests that vendors and organizations can use to verify their compliance. This certification provides a common ground for interoperability, ensuring that a FAPI-compliant client from one vendor can work seamlessly and securely with a FAPI-compliant authorization server from another.

Choosing certified components reduces the burden of security auditing and provides assurance that the system adheres to the industry's highest standards.

References and Further Reading

For more technical details on the specifications mentioned, consult the following official resources:

To learn more about FAPI 2.0 from a developer’s perspective, download the free ebook A Developer’s Guide to FAPI, which provides a detailed overview of the various security measures to make your application FAPI-ready.

Why Your Demo Code Should Be Treated as Production Code (And Other DevRel Secrets) 🎸

Carla Urrea Stabile — Thu, 29 Jan 2026 10:38:56 +0000

Have you ever found a code snippet in a tutorial, spent an hour trying to make it work, only to realize it’s using a deprecated library from 2019?

We’ve all been there.

I recently sat down with Sam Bellen, Principal Developer Advocate at Auth0, for the first episode of the Making Software podcast. We talked about the "diplomatic" nature of Developer Relations, the controversy of "selling" to developers, and why we need to stop treating demo code like a second-class citizen.

Here are the key takeaways for every developer, whether you’re looking to break into DevRel or just want to build better software.

1. DevRel: Part Engineer, Part Diplomat 🤝

Sam and I agreed on a unique definition: DevRel is a mix of developer and diplomat.

As a developer, you’re used to talking to Product Teams to understand requirements. In DevRel, that flow often reverses. You are the "voice of the developer" inside the company.

"It’s building relationships with the product teams... at a certain point, they will start trusting that what you’re telling them is actually valuable feedback instead of just randomly pinging people on Slack." — Sam Bellen

The Lesson: If you want to influence a product's roadmap, don't just throw bugs over the fence. Build a relationship with the people making the product. Trust is the currency of influence.

2. Authenticity > Sales 🚫💰

Developers are notoriously skeptical of being "sold" to. We can smell a marketing pitch from a mile away. Sam’s approach? Lead with the problem, not the product.

Instead of saying, "Use our auth tool because it's great," talk about how hard it is to implement DPoP (Demonstrating Proof-of-Possession) or Passkeys manually.

When you illustrate the complexity of a problem, the solution (your product) becomes a natural part of the conversation rather than a forced advertisement.

3. Treat Demo Code as Production Code 🛠️

This was Sam’s biggest take: Any code you write (even a tiny sample for a blog post) should be treated as production code.

If a vulnerability is found in a framework, DevRel teams should be the first to update their samples. Why? Because that sample is often a developer's first "touchpoint" with your tech.

Why this matters:

Security: Developers often copy-paste samples directly into their projects.
Trust: If your "Quick Start" doesn't work out of the box, you've lost the user.
Maintenance: Technical debt exists in docs, too. Set aside time (Sam recommends monthly) to audit your repos for deprecated APIs.

4. Get Your Hands Dirty with the Spec 📖

Sam has a "superpower": he actually likes reading technical specifications. While most of us fall asleep reading an RFC, Sam uses them to build visual tools that explain what’s happening "under the hood."

"In order for me to explain something... I build it myself. Not a clone of the product, but a demo that implements the topic. I make loads of mistakes, get lots of errors, and eventually, I figure out what's happening."

The "Aha!" Moment: You don't truly understand a tool until you've tried to build the logic it simplifies.

Summary: Two Steps to Better Developer Experience

If you’re an engineer looking to improve the DX (Developer Experience) of your project today, start here:

Listen to your DevRel team: They aren't just "social developers." They have the technical baggage and the community feedback to tell you what’s actually broken.
Stop "dropping" code on GitHub: Don't just create a repo and ignore it. If it’s public, it’s "production" for someone else.

🎧 Listen to the Full Episode

Want to hear the full conversation about guitars, Passkeys, and the early days of DevRel?

Listen to the full episode here or in your platform of choice.

What’s your take? Should demo code be held to the same linting and security standards as the core product? Let’s talk in the comments! 👇

Auth0 for AI Agents is now generally available!

Jessica Temporal — Mon, 24 Nov 2025 16:32:18 +0000

Hey DEV Community! 👋

If you're building AI agents right now (and honestly, who isn't?), you've probably hit the auth problem. You know the one - where the quickest path to getting your agent working is to just hardcode some API keys and move on. It works great... until you need to actually ship to production.

Today, we're excited to share that Auth0 for AI Agents is now generally available, and it's designed to solve exactly this problem.

Auth0 for AI Agents

The Problem with Hardcoded Credentials

Let's be real: when you're prototyping an AI agent with LangChain or LlamaIndex, hardcoded credentials are the path of least resistance. Your agent needs to access Slack, GitHub, Google Calendar, or your own APIs, and frameworks make it easy to just plug in those keys.

But production is a different story:

What happens when your agent needs to act on behalf of different users with different permissions?
How do you handle token refreshing across 30+ different apps?
How do you let users approve critical actions (like making purchases) without giving your agent carte blanche?
How do you ensure your RAG-powered agent only accesses documents the user actually has permission to see?

These aren't edge cases - they're fundamental requirements for any AI agent that's going to interact with real user data and take real actions.

What We Built

Auth0 for AI Agents gives you four key capabilities:

1. User Authentication

Secure and scalable User Authentication allows you to identify who's talking to your agent and give it secure access to your first-party APIs. Your agent can access user-specific data like order history, preferences, or chat logs - all scoped to the right permissions.

2. Token Vault

Token Vault handles OAuth flows with 30+ pre-integrated apps (GitHub, Slack, Google Workspace, and more) plus any custom OAuth provider you want to connect. It manages access tokens, refresh tokens, and the whole lifecycle automatically. Your agent requests a connection, the user authorizes once, and you never have to think about token management again.

The SDK detects when a tool call needs authentication, pauses execution, prompts the user to authenticate, stores the token securely, and resumes automatically. On subsequent calls, it just works.

3. Asynchronous Authorization

Your agent can work in the background and only interrupt the user when it needs approval for critical actions. Using Client-Initiated Backchannel Authentication (CIBA), you can send approval requests via email or Auth0 Guardian (SMS coming soon).

4. FGA for RAG

When your agent uses Retrieval Augmented Generation to search through documents, it needs to respect access controls. Fine-Grained Authorization for RAG ensures that users only get answers from documents they actually have permission to access.

Why This Matters

AI agents are moving from demos to production. The difference between a hackathon project and a real product often comes down to handling auth correctly. We built Auth0 for AI Agents because we kept hearing from developers that this was the hard part - not the LLM integration, not the prompt engineering, but the secure, user-scoped access to real systems.

This isn't about adding features. It's about removing blockers so you can ship production-ready AI agents without building your own auth infrastructure from scratch.

Framework Support

We've built SDKs for the frameworks you're already using:

LangChain (Python & JavaScript)
LlamaIndex (Python & JavaScript)
Cloudflare AI
Firebase Genkit
Vercel AI SDK

Each SDK handles the OAuth dance automatically, so you can focus on building your agent's capabilities, not wrestling with authentication flows.

Get Started

Our free tier includes two connected apps in Token Vault, async authorization, and all the core features you need to start building. As you scale, we have self-service plans that grow with you.

Early-stage startups can apply for one year of Auth0 free.

Start Building Today

Let's Sketch Identity: Authentication vs. Authorization

Ramona Schwering — Wed, 24 Sep 2025 11:01:00 +0000

So, you are building an application and need a login form. In it, you’ll get the user's email and password, send them to an API, and... something happens. The user is logged in afterwards. But what is that something? How does your application decide who gets in and what they get to see?

This is the first article in a series called "Let's Sketch Identity." These blog posts will use my notes from when I started learning about identity concepts as a Developer Advocate. Think of them as my Identity Sketchbook, and join me on my journey back then! ❤️

In this series, I will show you the core ideas of modern identity using a simple, continuous story: no complex specifications, just clear, practical explanations for web developers. Today, I am starting with the two most important concepts: Authentication and Authorization. You can think of them as a Bouncer checking IDs at a door and a Clipboard listing your permissions.

What Is Authentication? The Bouncer Analogy

Do you know about the Persuadable Bouncer? It’s an exploitable four-panel comic series featuring a man in a suit blocking a door and allowing the entrance in the fourth panel. This is how I like to picture Authentication (and I just love to draw memes 😁). Okay, think of authentication like this: Authentication is the bouncer standing at the front door, e.g., of a venue. In real life, the venue is your application. To get in, you have to show your ID, which has your credentials.

Let's visualize this. In the first panel, we see our Bouncer blocking the door as a user presents their ID with their credentials. Once the Bouncer validates that ID, the lock clicks open, and as we see in the second panel, he finally opens the door.

And that’s it: You've been authenticated! The shorthand for this process is Authn.

At its core, authentication is proving that somebody or something is who they say they are. It's the lock on the door of your application. Talking about Authn in an Identity scenario usually means verifying credentials. These credentials come in all shapes and sizes; while a username and password combination is the classic example, they can also be a private and public key pair. Modern approaches even include passwordless authentication, which verifies a user’s identity with something other than a password, like a magic link sent to their email or a biometric trait like a fingerprint.

What Is Authorization? The Clipboard Analogy

Just because you are inside the room does not mean you can do whatever you want. This is where Authorization comes in, like the bouncer handing you a clipboard. Picture that clipboard as a checklist or ruleset explaining to you your permissions:

You see, the clipboard lists exactly what you are allowed to do. As you can see in the sketch, you might have permission to view rooms and make a guestbook entry, but the permission to change the AC settings is firmly crossed out. One crucial rule is that the bouncer will always check your ID before handing you the clipboard. You must first prove who you are before you can be given a list of things you can do.

My short take: Once a user enters the door, we must know what they can do. That's Authorization. Authorization checks whether somebody or something has access to a particular resource or is allowed to perform a specific action. The shorthand for Authorization is Authz.

How This Works in a Real-World Frontend Application

So, how does this story of the bouncer and the clipboard play out in a real web application? Let's walk through it.

A new user comes to your site and clicks on their "My Profile" link.
Your application’s bouncer stops them, sees they do not have a valid ID yet, and sends them to the login page.
The user provides their credentials (their ID). The system checks them and confirms their identity. Authentication is now successful.
Now that your application knows who the user is, it prepares their personal clipboard of permissions.
The user is sent to the "My Profile" page. They can see all their personal information, but the "Admin Panel" button is hidden. Why? Their clipboard says they do not have access to admin_panel permission. This is Authorization in action.

Understanding this difference is very important for you as a frontend developer, as it directly affects the UI you build daily. Some pseudo-codes show you how that logic might look inside a component. Does this look familiar to you?

// In some component that renders a navigation bar
function Navbar({ user }) {
  // The bouncer checks for an ID (Authentication)
  if (!user.isAuthenticated) {
    return <LoginButton />;
  }
  // If authenticated, the bouncer checks the clipboard (Authorization)
  return (
    <div>
      <WelcomeMessage user={user} />
      <ProfileLink />
      {/* Check the clipboard for a specific permission */}
      {user.hasPermission('access:admin_panel') &&
        <AdminPanelLink />
      }
      <LogoutButton />
    </div>
  );
}

However, no worries! This blog post will revolve around my sketch notes, so I have some prepared. Let’s take a look at this workflow:

You see, Authn and Authz are not the same thing. However, they belong together: Authentication is the first step (I’d even call it groundwork), so that Authz can take place. That makes sense, as you need to know your user before deciding on their permission, right?

But There Are Different Types of Clipboards!?

That simple .hasPermission('...') check in our code is powerful. However, it makes me think. How does the system decide on the user’s permissions in the first place? The bouncer's clipboard is not just a simple list. Let's take a quick look at the most common variations, as I depicted four types of clipboards in my sketches.

Role-Based Access Control (RBAC) assigns permissions to users based on their roles, such as “admin,” “editor,” or “viewer.” In the analogy I’m using in my sketches, this is like the “hat” the user wears. Instead of providing a single set of permissions, RBAC offers tailored permissions corresponding to each specific role.

Attribute-Based Access Control (ABAC) is an authorization model that determines access based on user attributes (or characteristics) rather than roles. It’s similar, but not the same as Policy-Based Access Control (PBAC): They are often considered the same, but are not. In our scene, these are the “tags” the user has on their conference badge, such as “Attendee”, “Speaker”, or the time when they check in. ABAC protects resources from unauthorized users and actions that do not align with the approved tags (which are basically attributes) established by an organization’s security policies.

Relationship-Based Access Control (ReBAC) handles access decisions based on a subject's relationships. Such a subject could be a user, device, or application. Or in our sketch, it’s visualized as a guest list, where only the family is added to. When a subject tries to access an event or a resource (in real life), the system evaluates the specific relationships tied to that subject to decide whether to grant access or not. In my analogy, it may look like this:

Last but not least, there’s Delegated Authorization. It allows a user to grant one application permission to access their data from another service, without sharing their password, just like someone presenting their ID and a document issued by someone else asking to let them enter the room on their behalf. The user would have to approve the access requested by the first party to be shared by the third party. This access is limited to the permissions that the user grants. For example, LinkedIn would only get access to our Gmail contacts, but not our inbox or calendar.

Conclusion

And that is it for my first sketch! The story is this straightforward:

Authentication (Authn) is the action done by the Bouncer: They check your ID to prove who you are.
Authorization (Authz) is the action of providing the Clipboard to the person, being the user. It lists what you can do once you are inside. And you can never get your clipboard until the bouncer has approved your ID.

Let's zoom out and look at the entire journey in a single picture to tie it all together. From the initial ID check by the Bouncer to the different kinds of Clipboards he uses, here is the full story from my Identity Sketchbook:

Great, your user is now authenticated and inside the application! ❤️ However, you might have already guessed, Identity does not stop here. How does the app remember them when they navigate from one page to another? They do not have to show their ID for every single click. How is their "clipboard" carried around with them?
In the next article, I will show you the answer: the Digital Passport, also known as the JSON Web Token (JWT). Stay tuned! 🔥

In the meantime, there's some interesting reads if you want to dive deeper:

How to Configure the Auth0 MCP Server in VS Code for AI Assistant Integration

Jessica Temporal — Mon, 08 Sep 2025 21:48:24 +0000

Not long ago we released the Auth0 MCP Server, a specialized Model Context Protocol server that brings Auth0's identity management capabilities directly to your AI assistant conversations in your favorite app or IDE. This server enables you to analyze authentication patterns, identify authentication related issues, and manage identity operations through natural language interactions.

This post will guide you through setting up the Auth0 MCP Server in your VS Code development environment and using it to perform some basic analysis.

What Is the Auth0 MCP Server?

The Auth0 MCP server provides a bridge between your AI assistant and Auth0's identity platform. Instead of manually navigating the Auth0 Dashboard or writing custom API calls, you can ask natural language questions like:

"Create an application for me"
"Show me recent failed login attempts"
"What applications are configured in my tenant?"

The server translates these requests into Auth0 Management API calls and returns the results in a format that your AI assistant can understand and present clearly.

Key capabilities

The Auth0 MCP server includes several tools for interacting with your Auth0 tenant:

User Management: Search, retrieve, and analyze user data across your tenant
Log Analysis: Query authentication logs to understand user behavior and troubleshoot issues
Application Management: Review and analyze your configured applications and their settings
Statistics and Analytics: Get insights into user activity, sign-ups, and authentication patterns

Prerequisites

Before configuring the Auth0 MCP server, ensure you have:

An Auth0 account with a configured tenant;
VS Code;
npx, get npx here.

That's everything you need to get started!

Initializing the Auth0 MCP Server Configuration

The Auth0 MCP Server needs access to your Auth0 account. To configure it, you need to:

Select the scopes: which actions the server can perform for you
Choose the tenant: also define which tenant to perform actions in

And add the configuration to your project by creating the mcp.json file with the settings in the appropriate location. So run the following command on the terminal:

npx @auth0/auth0-mcp-server@0.1.0-beta.7 init --client vscode

The Auth0 MCP Server is currently in beta and is provided as is, for that reason we recommend pinning the version whenever possible.

This will start the configuration wizard prompting you to select the scopes for the server.

Once you select the scopes, you'll receive a code in the terminal. You will use this code to verify your device when logging in to Auth0.

Authorize the Auth0 MCP Server for Your Auth0 Tenant

After selecting the scopes and pressing Enter, a browser window will open. This will take you to the Auth0 login page (if you are not logged in yet) and will ask you to confirm the device code you received in the terminal:

Once confirmed you'll be able to both select the tenant you want to use and double check the scopes:

Once the authorization process finishes you'll see a message like the one below.

If you haven't looked into the Auth0 MCP Server source code on GitHub you may be wondering, "How does this work?"

The Auth0 MCP Server uses device authorization flow to enable your access to the Auth0 Management API while running tools.

Under the hood, when you finish logging in and authorizing the application, the Auth0 MCP Server will store in the system keychain (or similar depending on your operating system) the Auth0 access tokens and a few extra bits of information.

This step guarantees that the LLM in your AI assistant cannot access your Auth0 access token. The token is stored securely and is only retrieved by the MCP server when needed to perform an action.

Stepping back into our configuration: feel free to close the browser with the confirmation screen and return to the terminal to finish the setup.

Choose Where to Configure the MCP Server for VS Code

For VS Code, differently than Cursor and Claude, you can set two levels of access:

Workspace: Configure for a specific project/repository;
Global: Configure for all VS Code instances

Following the principle of least privilege, you should ideally configure your MCP Server at the Workspace level. However, if you use the same server across multiple projects, a Global configuration may be more practical.

In this blog post we are going to use the Workspace approach to make sure only our project has access to the Auth0 MCP Server.

When you choose "Workspace" for your MCP server a .vscode/mcp.json file will be created in your project. If you are performing these steps within VS Code, the file will automatically open, and you'll see inline commands like this:

If you open VS Code in the directory you selected during the configuration step, the server should already be up and running.

Testing the Auth0 MCP Server Configuration

Once configured and the login is made, you can verify that the server is working properly through the VS Code interface.

Checking server status

Navigate to the Extensions tab and look for your Auth0 MCP server in the servers list
Click on the server entry to see its status and available tools
Check the output logs to ensure the server started successfully and connected to Auth0

Changing the tenant

If you want to change the tenant, run the init command once again. You’ll go through the authorization flow again and see the page where you can choose a different tenant.

Using the Auth0 MCP Server with GitHub Copilot for Analysis

With the server configured, you can now interact with your Auth0 tenant through GitHub Copilot Chat in VS Code. Set the Copilot mode to "Agent" and start asking questions like the ones below.

“How many applications do I have in Auth0?”

“Give me stats about login activity from the past 1h”

“What recent logs do I have?”

Keep in mind that if you have other MCP servers that manage logs you might need to be more specific in your question by adding an “Auth0” in it so it knows which server to use.

Next Steps

Setting up the Auth0 MCP server in VS Code creates a seamless bridge between your development environment and your identity infrastructure. Key takeaways include:

Security First: Always prioritize secure credential management and follow the principle of least privilege
Environment Separation: Use different configurations for development, staging, and production tenants
Workflow Integration: The real value comes from integrating identity queries into your daily development workflow
Monitoring and Compliance: Maintain awareness of data access patterns and compliance requirements
Team Collaboration: Share common queries and best practices with your development team

The Auth0 MCP server transforms identity management from a context-switching activity into a natural part of your development conversation. Whether you're troubleshooting user issues, analyzing authentication patterns, or reviewing security configurations, you can now handle these tasks without leaving your IDE.

This integration represents the future of developer tooling: AI-assisted workflows that bring complex systems closer to the point of development. As MCP adoption grows, we can expect similar integrations across the entire development stack.

Start using the Auth0 MCP Server and let us know what you think below

How to Build a Python MCP Server to Consult a Knowledge Base

Jessica Temporal — Thu, 28 Aug 2025 13:37:00 +0000

Let's say you have a blog that you want to be able to consult from your AI assistant like Claude, how would you do it? In today's world of AI-powered tools, the easiest way would be to create an MCP (Model Context Protocol) server that can access the blog in some way and find what you are looking for.

I often use my own blog as a source of information. I think of it as my public field notebook, the only issue with that is that my blog is not "searchable", it doesn't have a built-in search feature, so I often use the site:jtemporal.com <topic> Google search trick to find what I'm looking for.

I have also been using AI assistants like Claude for writing and editing my content, and with the rise of MCP I'd love to search my own content through the chat instead of interrupting my flow to search for information on a separate application.

In order to make this information available we will build an MCP server in Python and learn how to configure it in Claude Desktop. Let's get started, shall we?

How our MCP server works

Our MCP server will run locally and act as a bridge between Claude and the blog content:

This flow shows how Claude can access your blog content using SerpAPI and how it can obtain the content of a given blog post without you ever leaving your conversation by leveraging the MCP server. That means you don't have to switch between interfaces and break your flow.

What Is Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open standard that enables AI applications to securely connect to external data sources and tools. Think of it as a bridge between your AI assistant and various resources. For the GenAI-powered apps using an MCP, it doesn't really matter what the resources are, they could be files, databases, APIs, or in our case, blog posts stored in a GitHub repository.

MCP allows AI models to:

Access external data through standardized interfaces
Use tools to perform actions on your behalf
Maintain security boundaries between the AI and your data

In our case, we'll use MCP to give our AI assistant the ability to search through blog posts, making your personal knowledge base accessible without having to switch contexts.

To learn about MCP and auth read An Introduction to MCP and Authorization

Model Context Protocol (MCP) SDKs and other libraries

MCP already has a few SDKs you can start using. For this blog post we will use the MCP Python SDK.

We'll also use the SerpApi library to search for blog posts without needing to manage search infrastructure ourselves. SerpApi provides a simple API for performing site-specific Google searches, which is perfect for finding content on your blog.

For package management, we'll use uv, a modern Python package manager that's significantly faster than pip and handles virtual environments automatically. Using uv will also make it easier to setup the server within Claude.

Setting Up the Application

Let's get our MCP server up and running using uv:

Install uv: you can learn how to do that on your system on the uv docs.
Clone the repository: For this tutorial, you can follow along by cloning the repository which contains the setup for the code we'll build:

   git clone https://github.com/jtemporal/blog-search-mcp-in-python.git
   cd blog-search-mcp-in-python
   git switch base-app

Initialize the project with uv: This creates a virtual environment and installs dependencies

   uv sync

Configure your blog repository settings by copying the example configuration file like so:

   cp .config.example .config

Then edit .config to match your blog details:

   [MCP_SERVER]
   blog_base_url = https://yourblog.com
   serpapi_key = your-serpapi-key-here
   server_name = Blog Search Server
   log_level = INFO

To get the SerpApi key sign up for free here.
If you don't have a blog with llms.txt feel free to use mine: jtemporal.com

Test the setup

   uv run pytest tests/test_config.py -v

If you set everything up correctly, all 10 tests should pass. This validates that your configuration is loaded properly and the MCP server can access your settings.

That's it! The code is ready, let's update the MCP server and make sure we can use it in Claude. The uv approach automatically handles virtual environments and dependency management, making the setup much cleaner and more reliable.

Code structure

Our MCP server project has a clean, organized structure like this:

mcp-with-python-blog/
├── src/
│   ├── server.py          # Main MCP server implementation
│   └── config.py          # Configuration loader
├── tests/                 # All tests
├── .config                # Your blog configuration
├── .config.example        # Configuration template
├── pyproject.toml         # Python project configuration and dependencies
├── uv.lock                # Dependency lock file
└── README.md              # Development documentation

Note a few important aspects of our codebase structure:

Test Organization: The test suite in tests/ holds both unit tests with mock data and integration tests. We should run integration tests sparingly as they make real API calls to SerpApi, which count towards your monthly quota and take longer to run.
Configuration Security: The .config file contains sensitive data like your SerpApi key. Keep this file secure and never commit it to version control.
Clean Architecture: The src/server.py file contains the MCP server implementation where we'll define our tools for blog search and content retrieval.

Tool vs. Resources in MCP Servers

If I were to serve this MCP server as part of my website and in the same machine the blog is hosted today, the MCP server would have access to the files used to generate the blog pages. If this were the case we could use a resource like this to retrieve documents:

@mcp.resource("file://documents/{name}")
def read_document(name: str) -> str:
    """Read a document by name."""
    # This would normally read from disk
    return f"Content of {name}"

From the MCP documentation:

Resources are how you expose data to LLMs. They're similar to GET endpoints in a REST API - they provide data but shouldn't perform significant computation or have side effects.

But that's not the case. The blog is a simple static generated website using Jekyll, it is built and served through GitHub Pages. With that in mind it makes more sense to use tools and leverage tool calling.

Tools are more powerful than resources since you can use them to perform actions like the one below that sums two numbers:

@mcp.tool()
def sum(a: int, b: int) -> int:
    """Add two numbers together."""
    return a + b

But more than that you can also have tools to search for information in any knowledge base, and in this case a collection of blog posts.

In more concrete terms tool calling, in the context of GenAI and MCP, allows an AI model to execute specific functions. This is perfect for our use case where we need to search through blog posts based on user questions.

Creating the MCP Server

Navigate to src/server.py. You'll see some imports already in place: these are the libraries we'll use to build our MCP server. Now create the MCP server instance by adding this line at the end of the file:

mcp = FastMCP(name=SERVER_NAME)

The mcp object is our application instance. We'll use this object to define our tools that Claude can call. Next, we'll implement two tools:

search_posts: Search blog posts for specific topics or keywords
get_post_content: Retrieve the full content of a specific blog post

Search posts tool

The first tool we'll implement, searches for blog posts using SerpApi. This tool will leverage Google's search capabilities to find relevant posts on your blog by performing a site-specific search.

Add the following code to the end of src/server.py:

@mcp.tool()
def search_posts(query: str) -> str:
    search = GoogleSearch({
        "q": f"site:{BLOG_BASE_URL.strip('https://')} {query}", 
        "api_key": SERPAPI_KEY
    })
    search_result = search.get_dict()

    if search_result.get("search_metadata").get("status") == "Success":
        posts = search_result.get("organic_results", [])
        if posts:
            result = f"Found {len(posts)} post(s) matching '{query}':\n\n"
            for post in posts:
                title = post.get("title")
                url = post.get("link")
                snippet = post.get("snippet")
                result += f"**{title}**\n{url}\n{snippet}\n\n"
            return result

    return f"No posts found matching '{query}'."

Let's break down what is happening:

@mcp.tool(): This decorator registers the function as an MCP tool that your client can call. The decorator automatically makes the function available to the client with proper type information and documentation.
query parameter: This is the search term that users provide when they want to find blog posts. Claude will automatically extract this from the user's request.
SerpApi integration: We create a GoogleSearch object that performs a site-specific search using the site: operator. This limits results to only your blog domain.
Result processing: We extract the organic search results and format them into a readable response with titles, URLs, and snippets that give users a preview of each post.
Error handling: If no results are found or the API call fails, we return an appropriate message rather than crashing.

From an user perspective this is what happens when this tool is called:

Making the MCP Server Runnable

Finally, to make our MCP server runnable we need to add the following at the end of the file:

if __name__ == "__main__":
    mcp.run(transport="stdio")

This is the server entrypoint. The transport="stdio" parameter tells the MCP server to communicate through standard input/output streams. This is the recommended transport method for local MCP servers that integrate with desktop applications like Claude Desktop.

When Claude Desktop launches your MCP server, it communicates with it through stdin/stdout, making this transport layer perfect for our use case. In future deployments to cloud environments, you might use different transport methods like HTTP.

Testing the MCP Server with the MCP Inspector

Now you have a tool to work with. Let's use the MCP Inspector to figure out if everything is running as expected. In your terminal run the following command:

npx @modelcontextprotocol/inspector uv run src/server.py

This will use npx to run the MCP inspector, a tool for testing and debugging MCP servers.

On the left, click Connect so the inspector can connect to your server and then switch to the Tools tab on the right. Then click on List Tools, and you should see something like the image below:

You can even run a tool from this interface, go on, try it.

Get Post Content Tool

Your current tool can get your blog posts, but after finding a blog post you usually want to investigate the content you find interesting, so it is time to implement a second tool that can obtain a post content. This tool will leverage the llms.txt from the blog.

What is llms.txt?

The llms.txt file is a simple text file that serves as an index of your blog posts in a format optimized for AI consumption. It contains:

A header describing the content
Other sections about the blog
Links to raw Markdown files hosted on GitHub

It is structured in a way that's easy for both humans and AI to parse. Here's what a typical llms.txt looks like:

# LLM Feed for jtemporal.com

## Projects

- [GitFichas](https://gitfichas.com)
...

## All posts

Links to blog posts in Markdown format for easy LLM consumption.

- [How to Handle JWTs in Python](https://raw.githubusercontent.com/jtemporal/jtemporal.github.io/refs/heads/main/_posts/2023-04-06-how-to-handle-jwts-in-python.md)
- [Creating a Travel Diary With Django](https://raw.githubusercontent.com/jtemporal/jtemporal.github.io/refs/heads/main/_posts/2023-03-30-creating-a-travel-diaries-blog-with-django.md)
...

LLMs prefer Markdown as it is less noisy than an HTML would be, also less expensive to process since you'll have fewer embeddings generated by Markdown than you would by HTML.

Getting started with GenAI and LLMs? Check out RAG and Access Control: Where do you start?

Add the following code after the first tool and before the if __name__ == "__main__": clause in src/server.py:

def get_post_content(title: str) -> str:
    try:
        # Fetch the llms.txt content from the blog
        llm_url = f"{BLOG_BASE_URL}/llms.txt"
        response = requests.get(llm_url, timeout=10)
        response.raise_for_status()

        # Parse the llm.txt content to find the post by title
        content = response.text
        lines = content.split('\n')

        # Find the "## All posts" section and extract posts from there
        raw_url = None
        in_all_posts_section = False

        for line in lines:
            # Check if we've reached the "## All posts" section
            if line.strip() == "## All posts":
                in_all_posts_section = True
                continue

            # Only search for posts within the "All posts" section
            if in_all_posts_section and title in line:
                # Extract URL from markdown link format: [title](url)
                if '](https://' in line:
                    raw_url = line.split('](')[1].strip(')')
                    break

        if not raw_url:
            return f"Post with title '{title}' not found in llm.txt"

        # Fetch the raw markdown content from GitHub
        content_response = requests.get(raw_url, timeout=10)
        content_response.raise_for_status()

        return content_response.text

    except requests.RequestException as e:
        return f"Error fetching content: {str(e)}"
    except Exception as e:
        return f"Error processing content: {str(e)}"

Let's break down what is happening:

@mcp.tool(): Once again, this decorator registers the function as an MCP tool that Claude can invoke when users want to read full blog post content.
title parameter: This is the blog post title that users want to retrieve. Claude will extract this from the user's request or from search results.
llms.txt integration: We fetch the llms.txt file from your blog, which serves as an index of all your posts with links to their raw Markdown content on GitHub.
Title matching: We search through the llms.txt index to find a post that contains the requested title in the "All posts" section. This allows for partial matches, making it easier for users to find posts.
Content retrieval: Once we find the matching post, we extract the GitHub raw URL and fetch the full Markdown content directly from GitHub.
Error handling: We handle various error cases like network issues, missing posts, or malformed index files gracefully.

When this tool is called this is what happens:

Setting Up the MCP Server in Claude Desktop

Now that we have a working MCP server with two tools, let's configure it in Claude Desktop so you can use it for searching your blog posts during your conversations.

Before setting up the server in Claude Desktop, make sure you have:

Completed the server setup from the previous sections (including uv installation)
A working SerpApi key in your .config file
Claude Desktop app installed on your computer

Configuring Claude Desktop

Claude Desktop uses a claude_desktop_config.json file for MCP server configuration. Since we used the MCP SDK there's a easy way to configure our server in Claude, use the following command:

uv run mcp install "src/server.py" --with google-search-results

This will create the configuration file for you. Now restart Claude and check in the preferences if the server is running: Open the Settings, then access the Developer section. If your server is running as expected you should see something like the image below:

Testing the search blog tool in Claude

Now open a new conversation and ask something like: "Can search my blog for posts on pyenv?" Claude should identify your intent, recognize pyenv as the query for the search_posts tool, and offer to use it like so:

After a second you should see a result like this:

This means that Claude parsed the result of the search into a readable result for the chat for you.

Testing the post content tool in Claude

In the same conversation ask something like: "Can you get the content for the first post?" This time Claude should identify the get_post_content tool as well as post title and ofer to use the tool passing along the query like so:

After a second you should see a result like this:

This means that Claude parsed the result of the blog post to show it to you. Keep in mind that this is not a copy of the content on the page but what Claude understood from the blog post.

Tip: If you want you can also configure the server in Cursor, we left instructions in the repository's README.md on how to do it.

Recap and Future Steps

You've successfully built a complete MCP server that can search through your blog posts using Python! Here's what we accomplished:

Created a functional MCP server with two tools:

search_posts: Site-specific search using SerpApi
get_post_content: Full content retrieval via llms.txt indexing

Integrated with modern APIs using SerpApi for reliable search functionality

Implemented content indexing using the llms.txt standard for AI-optimized content access

Added comprehensive error handling and logging for robust operation

Configured Claude Desktop integration for seamless AI-powered blog search

Key benefits

Simple local server: SerpApi and llms.txt require minimal setup and you can run it locally
Reliable search: Leverages Google's search quality for finding relevant content
Fast content access: Direct GitHub raw content fetching bypasses the GitHub API rate limits
AI-optimized: llms.txt format is specifically designed for LLM consumption

What's next?

The MCP ecosystem is rapidly growing, and your blog search server is just the beginning. In a future blog post we will cover how to protect your MCP server to avoid abuse and how to deploy it to Claude so you can access it anywhere without having to have the code locally.

The complete code for this blog post is in this repository.

If you are building GenAI applications make sure you are protecting your user's data and giving the right level of access to your LLMs with Auth for GenAI. Sign up for the Auth for GenAI Developer Preview program.

We've been writing a lot on GenAI applications and tool calling, check out the related blog posts section below to continue learning and keep an eye out here or on our Community Forum to learn when the next part of this series go live.