DEV Community: Andrea Chiarelli

Generative AI and Non-Determinism

Andrea Chiarelli — Tue, 31 Mar 2026 07:12:49 +0000

“The limits of my language are the limits of my world.”

– Ludwig Wittgenstein

We often hear that generative AI is non-deterministic because it responds differently each time to the same prompt. This quality is both fascinating, because it is, in a sense, creative, and problematic, because it eludes our control in contexts where precision and predictability are essential.

So, is non-determinism really what lies behind the processing of an LLM?

What Is Non-Determinism?

To understand what non-determinism is, we need to turn to the theory of computation.

Imagine you’re in a maze. In a deterministic system, you are a lone explorer. You come to a fork in the road and choose the right path. If the path is blocked, you must go back (good old backtracking) and try the left path.

In a non-deterministic system, however, you possess the gift of ubiquity. When you reach the fork, you split into two people. One goes right and the other goes left.

According to Michael Sipser, the author of the book Introduction to the Theory of Computation, this process is perfect parallelism: just one clone needs to find the exit for the entire machine to succeed. The computation of a non-deterministic machine is not expressed as a transition from one state to another, but rather as a transition from one state to a set of states. This theoretical super-capacity is used to solve complex problems, such as those in the famous NP class.

In computer science, non-determinism is a model of logical perfection. If a solution exists, a non-deterministic machine will find it because it explores every possible path without ever making a mistake. However, be careful: there is no such thing as a purely non-deterministic physical computer.

The Many Faces of Non-Determinism

Before returning to generative AI, we need to clarify the various concepts of non-determinism that are often conflated in everyday language. In fact, the term’s meaning changes significantly depending on the context.

As we have seen, in computer science, non-determinism is a logical abstraction: a virtual perfect parallelism that allows us to solve a problem within a reasonable amount of time.

In physics, non-determinism, or more accurately, indeterminism, is the principle that it is impossible to simultaneously know two conjugate properties of a particle, such as position and momentum.

Biology also has the concept of indeterminism, though it is linked to the role of chance in the evolution of living beings. This chance seems to be present in other aspects of nature, such as the weather, which are so difficult to predict that they appear non-deterministic. In reality, these are not non-deterministic systems, but rather highly complex deterministic systems, as chaos theory explains.

Generative AI is often defined as non-deterministic because of the chaos effect: small variations in the input produce different outputs. However, as we will see, its nature is quite different.

AI and Probability

When you ask an LLM to answer a question or write code, the system doesn't use a non-deterministic approach to find the solution. The LLM simply… guesses.

LLMs are probabilistic machines, not non-deterministic machines. Their entire universe boils down to assigning a probability percentage to the next token. For example, if you write, “The cat is on the...”, the model isn’t thinking about physical space. It calculates that:

carpet has an 80% probability.
lawn has a 15% probability.

Unlike Sipser’s non deterministic machine, an LLM doesn’t traverse all logical branches. It chooses one based on a statistical distribution. This is a substantial difference!

A non-deterministic machine would virtually always give the correct solution. It would explore all possible branches of the computation to identify the correct one. If a solution is incorrect, that branch of the computation simply ends. There cannot be an output that is not a valid solution to the problem.

The LLM follows likelihood, not truth. It can generate a grammatically perfect sentence that is factually false because those words sound good together statistically. For instance, the LLM might tell you that the capital of Brazil is Rio de Janeiro because Rio is associated with Brazil much more often than Brasília in its training data. Statistically, Rio is the more likely answer, even if it is logically incorrect.

Why Is Imprecise AI Useful?

If AI is fallible and imprecise, why is it revolutionizing the world? Why is it permeating our daily lives?

Traditional, deterministic software is like a train traveling on tracks. It only does what it was programmed to do. It doesn’t make decisions beyond what the programmer intended, and it doesn’t evolve on its own. Traditional software expects input in a specific format. It cannot handle ambiguity or imprecision. For example, if you want to reschedule an appointment from today to tomorrow, you can do so by following one of a few predefined methods.

In contrast, if you ask a chatbot “Move today’s appointment to tomorrow,” or “Move today’s meeting to tomorrow,” or even “Tooday’s apointment goes to tomorow,” it uses its probabilistic nature to correctly interpret your request.

This ability to handle unstructured data, such as analyzing the sentiment of an email, summarizing a document, or translating a text, cannot be reduced to simple, rigid rules. In these cases, probabilistic flexibility is the only way.

Navigating Uncertainty

For now, non-determinism remains a logical ideal of supreme efficiency. However, what we actually have at our disposal is an extraordinary probabilistic tool that is not intended to replace traditional deterministic software, but rather to enhance it.

As developers and engineers, our task is not to eliminate AI's unpredictability, but rather to learn how to channel it. We must design deterministic systems around probabilistic engines that know when to be intuitive and imaginative and when to be precise.

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:

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.

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.

What a Developer Advocate Is Not

Andrea Chiarelli — Fri, 03 Oct 2025 16:20:32 +0000

Someone: "What’s your job?"

Me: "I'm a developer advocate."

Someone: "Oh, cool! Like... what do you do exactly?"

Me: "Well, my job is to make it easier for developers to adopt and use a product."

Someone: "Oh, so you work in sales?"

Me: "No, no. I don't sell the product. I help developers use it effectively, for example, by providing code samples, tutorials, articles, and so on."

Someone: "So are you a blogger? Or a technical writer?"

Me: "Well… maybe partly, but that's not all. I support the community and try to understand the pain points developers experience with the product so I can provide that feedback internally to improve it."

Someone: "Oh, right. Uhm… well, that's interesting..."

I’ve had many conversations like this. And often, the other person walks away with a very confused idea about the kind of work I do. I know, it's not easy to explain what I do for a living in just a few words. That's why I wrote a little book that tries to explain it. In this article, however, I want to focus on what a developer advocate is not.

A Developer Advocate Is Not…

It's natural to try to relate a new concept to something you already know. We always do it whenever we have to learn something new. Keeping that familiar concept in mind helps us understand the similarities and differences.

While understanding a new concept by looking at what it's not is not the most efficient process, it's the most natural way to frame it, at least initially. So, let's define what a developer advocate is not by comparing this role to a few common assumptions.

…a Salesperson

The goal of a developer advocate is not to sell a product. Although they aim to influence, their purpose is not to sell. Rather, they seek to improve the product so that it meets the real needs of developers. This influence moves in two directions:

Outward (from the company to the developer community), to teach developers how to best use the product.
Inward (from the developer community to the company), to convey their feedback to the company and encourage improvements.

Developers don't trust marketing promises; they trust other developers who have experience with a product and understand its technical details. A developer advocate builds this trust through technical competence, not sales techniques.

…a Copywriter

Although writing is one of their core skills, the role of a developer advocate differs from that of a copywriter. The fundamental difference lies in the purpose of the communication. Content created by a developer advocate is meant to stimulate interaction and feedback. Their work is not about promoting a brand; rather, it is about starting a technical conversation with the developer community. Their work is part of an ongoing dialogue aimed at improving the developer's experience with the product.

…a Blogger

Another common oversimplification is confusing a developer advocate with a blogger. While they may manage a blog and write articles, this is just one activity among many and one communication channel among many. Unlike bloggers, whose primary focus is content creation, developer advocates have the crucial responsibility of inbound advocacy. Their job doesn't end when a post is published. Rather, it continues by actively gathering comments, criticism, and suggestions from the community and bringing them back internally to influence product decisions.

…a Technical Writer

There is a clear distinction between a developer advocate and a technical writer. Technical writers create a product's documentation, which, by nature, has an impersonal style and follows specific rules to guide users. Technical documentation implies one-way communication from the company to the user. In contrast, a developer advocate's content is personal and carries the author's imprint. Its goal is to establish a human connection. Their goal is not only to explain "how to do something," but also to stimulate dialogue, answer questions, and build trust.

…a (Mere) Presenter

Although presentation skills are important, a developer advocate is more than just a presenter of technical content. They are, first and foremost, experienced developers. Their credibility comes from their ability to write code, understand development complexities, and “feel the pain” of other developers, not just from their public speaking abilities. Presentations at conferences or in videos are merely a means of communication and are not the essence of the role. Without direct, in-depth development experience, they would be unable to earn the community's trust.

Conclusion

Now that we've ruled out some of the professions it can be confused with, you probably want to know what a developer advocate is. What do they do? What value do they bring to a company that builds products for developers?

It would take too long to explain here. Find out by downloading my booklet “I Am a Developer Advocate”. It's free! And let me know what you think!

Being a Developer in the Vibe Coding Era

Andrea Chiarelli — Tue, 26 Aug 2025 15:07:44 +0000

I was looking at results of the Stackoverflow Developer Survey 2025, and one aspect caught my attention: the percentages relating to developers' confidence in the accuracy of AI tools.

As mentioned in the comment on the results related to this question, more developers do not trust AI tools than trust them. In my opinion, this is good news, although I am concerned about that 3% who have a high level of trust in AI tools. This is not to demonize AI tools, but rather to address the evolving role of developers.

Developers and Libraries

Some time ago, I wrote an article about whether using a library or framework exempts developers from understanding the specifics of the underlying tools and technologies. I addressed this issue by referring to the cult book Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig. Paraphrasing the book, I identified three types of developers:

The classic developer, who cannot resist the curiosity to see how a tool works. If possible, they will even venture into modifying it. This is what we commonly call a hacker.
The romantic developer, who just uses the library or framework as it is. He is more interested in achieving his desired result and appreciates the library more for how easily it allows him to do so than for how it works internally. The details of the tool are none of his business.
The pragmatic developer uses the library to solve a problem but does not overlook the advantage of understanding how it works internally. They may not know all the internal details of the library, but they have a high-level understanding of its architecture and can delve deeper if necessary.

Looking at the data on developers' trust in AI tools, I was reminded of that article. I thought that, nowadays, that classification and the need for pragmatic rather than romantic developers is even more relevant. If we want to translate this classification in terms of trust, the classic developer does not trust the tool; the pragmatic developer trusts it to a certain extent but tries to keep everything under control; and the romantic developer has blind faith in the tool.

If blindly trusting a traditional library has its drawbacks, then how can we trust code generated by an AI tool?

Towards a New Way of Being Developers?

With the rise of vibe coding, a new Romanticism of software development seems to have emerged, generating widespread enthusiasm. However, if code written by a developer is often unreliable, how can we trust code generated by an AI tool that has no real understanding of what it is doing? I am referring, of course, to tools based on LLMs, the current mainstream of AI.

The answer is that we should not trust it. Ever!

Should we give up on AI code generation tools? Absolutely not! We should use them because they can improve the quality of our code more than increase the production speed.

However, we should avoid becoming romantic developers who get excited because we can accomplish in a couple of hours what would have taken days or even weeks a few months ago. We must be pragmatic and verify that the generated code does what we expected. If we want to take it a step further and become classic developers who understand how the tool generated the code, even better. At the very least, it will help us formulate better questions.

The developer's job is not—and never has been—to produce code. Their job is to provide a solution that works as expected. As a vibe coder, you are responsible for verifying the code generated by the AI tool. You must understand the code and modify it if necessary. Some of the time saved by using the AI tool will need to be spent reviewing the results.

In short, you should never trust what an AI tool proposes. You must always analyze and validate the results. This means that you cannot stop learning programming languages, their best practices, design patterns, and the technologies on which your application is based. You will also need to learn the new things that the generated code will probably include.

Keep in mind that if something goes wrong—rarely does everything go smoothly—you are responsible for the code generated by the AI tool.

The Developer Is Dead. Long Live the Developer.

To those who think that AI will replace developers, I would say that they are right. In a few years—or even months—there won't be any more developers. There will be no more developers as we understood them until a few years ago.

Once the Romanticism of software development has passed, we will find that the role of developers has been redefined and probably expanded. We will likely have a new title, such as "code manager" or "coded solution provider."

However, there will still be a need for technical skills in code review and validation: high-level skills that minimize bugs and security issues in code generated by AI tools.

We cannot afford to be romantic developers who blindly trust the code generated by AI tools. Professional developers should never accept code produced by an AI tool without question. They must question it, employing the critical thinking that many believe is threatened by AI. After all, the saying "Trust, but verify" still holds true.

.NET MAUI Authentication on Windows: The OpenID Connect Challenge

Andrea Chiarelli — Tue, 06 May 2025 10:36:39 +0000

I'm not an expert desktop and mobile developer. My experience in this field is from a while ago, particularly in mobile development, where I wouldn't claim professional competence. Most of the time, I've created desktop console applications supporting backend processing. Still, I know how hard it is to build native applications with a GUI, especially when cross-platform support is required.

When I heard about .NET MAUI, I immediately thought it would be an ambitious and very interesting project. Several development teams dream of having a single codebase (or so) for applications that can run on different platforms.

.NET MAUI and OpenID Connect

I had the chance to play with MAUI to explore the integration with Auth0 authentication, which is based on OpenID Connect, a standard authentication protocol. However, since my first attempt around mid-2022, I immediately ran into issues on the Windows platform.

As you may know, OpenID Connect is a browser-based authentication protocol. This means that authentication is performed by opening the Identity Provider's login page in a system browser window. Auth0's experience is similar to what happens when you access a website using your Google or Facebook account.
While you might consider using an embedded WebView in your native application, best practices recommend launching authentication in a separate system browser window. Among other things, this allows you to benefit from Single Sign-On. But let's not digress.

.NET MAUI leverages the WebAuthenticator class to initiate the browser-based OpenID Connect authentication flow. While this approach provides a seamless experience for user login on platforms like Android, iOS, and macOS, developers encounter significant challenges with Windows when implementing secure authentication in their .NET MAUI applications. This was true three years ago, and it is still true at the time of writing:

A Frustrating Experience

You know, I'm not the only one surprised by this issue. If you take a look at the long threads around this issue, you can see many developers are complaining about the missing support for a very common feature such as authentication in Microsoft's own operating system!

But developers are not sitting idly by. Some have rolled up their sleeves and found workarounds. My colleagues on the SDK team have also implemented a solution inspired by the one adopted by WinUIEx.

Thanks to this workaround implemented by the Auth0 MAUI SDK, I was able to create some sample apps, write some tutorials, and add a MAUI template to the Auth0 Templates for .NET package.

Everything worked fine until .NET 9. With the latest release, once again, OpenID Connect integration stopped working in applications migrated to .NET 9, and the threads restarted (if ever they have actually stopped).

We also had some requests for help in the Auth0 Community forum.

The Ongoing Journey of .NET MAUI Authentication on Windows

Bottom line, MAUI developers had to revise their workarounds to fix the OIDC integration once again. My colleagues on the SDK team were also great in finding a way to fix the issue once again and update the MAUI SDK to support OIDC in .NET 9. On my side, I took the opportunity to update the Auth0 Templates for .NET package just in these days and provide you with a working .NET MAUI template for Windows.

From some ongoing discussions, it seems like there is a glimmer of light for the future. It goes without saying that every MAUI developer is looking forward to the resolution of this complicated relationship between MAUI, OpenID Connect, and Windows.

And you? What has been your experience integrating OpenID Connect authentication in MAUI applications on Windows? Share your story below.👇

Letter to Blazor

Andrea Chiarelli — Mon, 10 Mar 2025 17:34:33 +0000

Dear Blazor, I met you when you were still in your infancy. I started playing with you when you could barely stand up...

The Promise

Even though you were still frail, your ambition was exciting: to allow developers to create web, desktop, and mobile applications using only C# and Razor. Not bad at all. It was a bit like dreaming of becoming an astronaut when you grow up. 🧑‍🚀

You started with the web, promising to dethrone JavaScript and do much better than that old-timer. You promised that developers only need to know C# and Razor to create efficient web applications, whether they run on the server or the browser. No more complications to make a SPA communicate with the server. You, developer, create your components in Razor and all the logic in C#. The framework will take care of transforming everything into an application that runs on a web server or in a browser. Don't worry. Everything will happen behind the scenes in a linear and transparent manner. 🚀

Old Memories

Who knows why, but those promises brought to my mind something already seen: memories that I thought I had completely erased resurfaced. The promise of Web Forms resurfaced in my memory: a unified paradigm for web development, whether the application logic runs on the server or the client. The framework would have taken care of doing the right thing. This promise created quite a few disappointments at that time. Many developers who were approaching Web programming for the first time got confused. But perhaps now things have changed, times are different, we have different technologies. Blazor is not Web Forms. 🤔

What a Wonderful World

You, Blazor, have made it possible to create fantastic applications that run on the server and on the browser. You enabled components that can be shared between the server and the client. And your followers are not few. You have enchanted many. Not just those who hated JavaScript - that was easy - you also attracted those who were familiar with JavaScript. In short, your dream was within reach.

You enabled the reuse of the same Razor components in MAUI to create desktop and mobile applications, as you promised. Many .NET developers have started to idolize you. 😍

With .NET 8, you've gone further. Not only can developers use the same programming model to build server and client applications, but now they can decide at the level of individual components whether it should run on the server or the client. They can even decide that a component starts as a server component and becomes a client component. Crazy stuff! 🤯

A Crack in the Wall

Even though I have followed your growth, I can't say I know you well. I only played with you in a limited scope. I have a narrow view of you, I admit it. But the little I got to know about you left me a bit puzzled.

Ok. Many of the promises you made, you kept. But from what I could see, there are aspects that resemble me - no offense - more like a big deception. 😒

You promised that we wouldn't have to worry about JavaScript anymore, but every now and then there are things that you don't allow us to do. And so we inevitably have to communicate with the old man through JSInterop, and it's not a walk in the park.

You promised a unified programming model, where we didn't have to come up with tricks to circumvent programming problems that the not-so-simple coexistence of JavaScript and HTML has accustomed us to. I would have been a unified and consistent model where we create a component and don't need to worry about how and where it will be rendered and executed. The framework will handle everything.

So, we write an interactive auto component that needs to make an HTTP call to the server. Follow all the simple rules, but it doesn't work. Why? You also have to register HttpClient on the server. But why? Due to how the framework works under the hood. 😨

And what about the combination of render mode and interactivity management? How should I go about making my application today? Interactive WebAssembly or Interactive Server? But maybe it's better Global Interactive Auto, so it takes care of everything. The best way to get a headache is the day something doesn't work and you can't go back. As someone said, Blazor is absolutely amazing, until it’s not.

Then, you want to add support for authentication. A fairly common operation. Which application is without authentication nowadays? You enter a nightmare. How do I transfer the authentication state between the server and the client parts of a Blazor application? Well, just implement a few classes here and there. Why? Didn't you promise us that there wouldn't be any more need for tricks and gimmicks to do simple things? Yes, but this depends on how the framework works. 😞

Ok, now with .NET 9 you've simplified it, but only after your supporters went crazy trying to get the server and client to communicate about the authentication state. And in any case, it’s still a developer’s burden to tell you what to do to make them transfer the serialized authentication state. But wasn't the framework supposed to take care of these details?

A Big Deception?

What about the programming model you promised us? You had promised us that it was no longer necessary to know how JavaScript works, its interaction with HTML, etc. You had promised us a simple and unified model — a model that abstracts the underlying complications: HTTP, HTML, JavaScript, AJAX, etc.

I feel like you replaced a complex model based on standard stuff with YOUR model. Now, instead of knowing how HTTP, HTML, and JavaScript work, I have to understand how YOU work internally to create my applications. And then I wonder: where is the gain? 🤔

P.S. This letter is not meant to be a complaint against the work done by the Blazor team. It is merely an invitation to not trust abstractions when they are pushed too far. Not all complexity can be hidden behind an abstraction. Even if the model proposed by an abstraction seems to work, you always need to have an idea of how things work under the hood when they don't behave as expected. Be enthusiastic, yet pragmatic.

Securing Blazor in All Its Flavors

Andrea Chiarelli — Thu, 27 Feb 2025 09:36:02 +0000

Since its first official release in .NET 3.0, Blazor has made a solemn promise to .NET developers: allow them to build web applications using just C# and the .NET platform, with no JavaScript and very little HTML. But Blazor’s goal was even more ambitious: becoming the reference framework for all types of applications, not just web.

Since then, the Blazor framework has gained considerable popularity among .NET developers, but not without some problems, inevitably due to its evolution. The framework's changes since its first release have significantly impacted developers' work, who have had to adapt their applications to accommodate its evolution.

Furthermore, while the idea of having a single framework to develop any type of application may seem great, this can hide pitfalls and complications when implementing standards-based authentication and authorization, such as those based on OpenID Connect (OIDC) and OAuth 2.0, for example. As you may know, you should use different flows to authenticate users based on the application type: server-rendered web application, single-page application, or native application.

In this article, we will focus on implementing authentication based on the different types of applications you can build with Blazor. We will provide guidance on best practices and direct you to practical implementations using Auth0.

The Blazor “Flavors”

We mentioned Blazor’s evolution earlier. Let’s briefly recap what it is about.

In the beginning, Blazor was released with two hosting models: Blazor Server and Blazor WebAssembly, also known as Blazor WASM.

Blazor Server applications are intended to run on the server, and the UI part sent to the browser communicates with the server part over a SignalR connection using WebSocket.

Blazor WASM applications are compiled into WebAssembly and run entirely on the browser. While you can host a Blazor WASM application on any web server (standalone Blazor WASM), a specific hosting model called ASP.NET Core hosted model allows you to simply host your application within an ASP.NET Core application, giving you more control over some server-side functionality.

With .NET 6.0, a new hosting model was introduced: Blazor Hybrid. This hosting model allows you to use the Blazor framework to build desktop and mobile applications using a hybrid approach, i.e., Razor components run directly in the native application.

With .NET 8.0, a significant change was introduced: render modes. This revolutionized the way the hosting model was understood until now. With the Server and WASM hosting models, either the entire application ran on the server, or it all ran on the client. With render modes, the components run on the server or client, not the entire application. Or rather, the developer can decide the level of granularity with which to run the various parts of their Blazor application on the server or client. This is a great opportunity to build high-performance web applications, but it also complicates things quite a bit in different contexts, such as authentication and authorization.

At the same time, the introduction of render modes practically deprecates the Blazor Server hosting model. From now on, Blazor applications that support render modes are called Blazor Web Apps.

With the proliferation of all these flavors of Blazor, what is the best approach to implementing OIDC and OAuth 2.0 for authentication and authorization?

Blazor Server

While Blazor Server may be considered deprecated, legacy applications based on this hosting model exist. From the OAuth 2.0 and OpenID Connect perspective, a Blazor Server application is a server-rendered application and should therefore be considered a confidential client. It will use the Authorization Code flow to obtain ID and access tokens.

In code terms, this means that your Blazor application will use the OpenID Connect middleware, as in the following example:

builder.services.AddAuthentication(options =>  
  {  
 options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;  
 options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;  
  })  
 .AddCookie()  
 .AddOpenIdConnect("myOidc", options =>  
  {  
 options.Authority = $"https://{builder.Configuration["Oidc:Domain"]}";

 options.ClientId = builder.Configuration["Oidc:ClientId"];  
 options.ClientSecret = builder.Configuration["Oidc:ClientSecret"];  
 options.ResponseType = "code";  
});

If you use Auth0 for authentication, you can leverage the Auth0 ASP.NET Core Authentication SDK to simplify things.

Read this article to learn how to add Auth0 authentication to your Blazor Server application. As an additional resource, this article explains how to overcome an issue with logout that affects Blazor Server due to SignalR's behavior.

Blazor WebAssembly

Since Blazor WASM applications run entirely in the browser, they can be considered single-page applications, i.e., public clients. In this case, you must use the Authorization Code flow with PKCE to get ID and access tokens.

In terms of implementation, you need a specific WebAssembly package for your application, the Microsoft.AspNetCore.Components.WebAssembly.Authentication package. Your code for configuring OIDC will be as follows:

builder.Services.AddOidcAuthentication(options =>
{
  builder.Configuration.Bind("Oidc", options.ProviderOptions);
  options.ProviderOptions.ResponseType = "code";
});

You also need to add a reference to the AuthenticationService.js script in the index.html file of your application, as shown below:

<!DOCTYPE html>
<html>
  ...
  <body>
    ...
    <script src="_framework/blazor.webassembly.js"></script>
    <script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/AuthenticationService.js"></script>
  </body>
</html>

Read this article for more details on how to add Auth0 authentication to your Blazor WASM application. The article uses the ASP.NET Core hosted model, but the authentication configuration is the same even for standalone Blazor WebAssembly applications. To learn about building Blazor WASM applications to host in Azure Static Web Apps, read this article. Finally, take a look at this article to learn how to use Auth0’s Role-Based Access Control (RBAC) in both Server and WASM hosting models.

The Chaos of Blazor Render Modes

As you can see, identifying the correct authentication approach with the Server and WASM hosting models is quite straightforward: the first follows the confidential client approach, and the second follows the public client approach.

The introduction of render modes complicates things a bit. Indeed, in this case, part of an application runs on the server, and part runs on the client. To complicate the situation even more, with the interactive auto render mode, a component is initially rendered on the server and then on the client. What category does a Blazor application fall into in this case? Is it a confidential client or a public client?

Actually, there is no definitive general answer to this question. Much depends on how the components and their related render modes are combined in a specific application. A conservative approach to implementing OIDC authentication in a Blazor Web App is to consider it a confidential client. This entails that you can reuse the same code to configure a Blazor Server application.

However, this opens a new problem: how do you determine whether or not a user can see a specific component based on its authentication state? If a user authenticates after the browser downloads a WASM component, how does the browser know the new user authentication state?

To solve this problem, you need to keep the server-side and client-side authentication states in sync. However, while you have to manually implement authentication state sync in .NET 8.0, .NET 9.0 simplifies this approach by providing native support for authentication state synchronization.

Read this article to learn the details of how to add support to Blazor Web Apps authentication.

However, problems are not just related to authentication. You should also take care of how to call remote APIs from your WASM components. Since you consider your Blazor Web App a confidential client, your WASM components do not receive any access token to call APIs. How can you deal with this scenario?

Don't be tempted to make the access token available to WASM components. As security best practices suggest, the best approach is to implement the Backend for Frontend (BFF) pattern. This article shows how to call APIs by implementing BFF in Blazor.

Blazor Hybrid Apps

As mentioned earlier, Blazor Hybrid allows you to reuse Razor components and the skills learned with the Blazor framework to create UIs for desktop and mobile applications. In this context, your Blazor application is hosted by a native application, typically developed with MAUI. In fact, the combination of Blazor and MAUI is also often called Blazor MAUI.

In this scenario, authentication is handled entirely by the native component of the Blazor MAUI application. That is, the OIDC configuration and the authentication process occur in the native code of MAUI. The Blazor part simply creates an authentication state based on the user authentication result. Here is an example of an authentication state definition for a Blazor MAUI application using the Auth0 MAUI SDK:

public class Auth0AuthenticationStateProvider : AuthenticationStateProvider
{
    private ClaimsPrincipal currentUser = new ClaimsPrincipal(new ClaimsIdentity());
    private readonly Auth0Client auth0Client;

    public Auth0AuthenticationStateProvider(Auth0Client client) {
        auth0Client = client;
    }

    public override Task<AuthenticationState> GetAuthenticationStateAsync() =>
        Task.FromResult(new AuthenticationState(currentUser));

    public Task LogInAsync()
    {
        var loginTask = LogInAsyncCore();
        NotifyAuthenticationStateChanged(loginTask);

        return loginTask;

        async Task<AuthenticationState> LogInAsyncCore()
        {
            var user = await LoginWithAuth0Async();
            currentUser = user;

            return new AuthenticationState(currentUser);
        }
    }

    private async Task<ClaimsPrincipal> LoginWithAuth0Async()
    {
        var authenticatedUser = new ClaimsPrincipal(new ClaimsIdentity());
        var loginResult = await auth0Client.LoginAsync();

        if (!loginResult.IsError) {
          authenticatedUser = loginResult.User;
        }
        return authenticatedUser;
    }

    public async void LogOut()
    {
        await auth0Client.LogoutAsync();
        currentUser = new ClaimsPrincipal(new ClaimsIdentity());
        NotifyAuthenticationStateChanged(
            Task.FromResult(new AuthenticationState(currentUser)));
    }
}

Read this article for more details about adding Auth0 authentication to a Blazor MAUI application.

Use the Auth0 Templates

As you may have understood by now, there are many moving parts in the process of integrating OIDC and OAuth 2.0 with the many flavors of Blazor. Understanding why and how each approach works is important. It allows you to identify the source of any problems and understand why something goes wrong.

Once you understand which approach to take for each Blazor flavor, you just need to correctly implement the integration for each new application.

Auth0 provides you with project templates to make this job easier. The Auth0 Templates for .NET package includes a few project templates for Blazor that you can use with the .NET CLI, Visual Studio, or JetBrains Rider.

For example, the Auth0 Blazor Web Application template allows you to scaffold a Blazor Web App application with Auth0 authentication embedded with just a command like the following:

dotnet new auth0blazor -o MyBlazorWebApp

If you have the Auth0 CLI installed on your machine and logged in to your Auth0 tenant, you can also get your application automatically registered with Auth0 and ready to run in less than one minute.

Alternatively, you can use your preferred IDE, such as Visual Studio, to generate your application and register it manually:

The package also provides a legacy Blazor Server template and a Blazor WebAssembly template in the ASP.NET Core hosted model.

Summary

At this point, you have a comprehensive overview of the different flavors of Blazor available so far and the issues you face when adding support for OIDC and OAuth 2.0-based authentication and authorization.

If you use Auth0 as your identity provider, follow the Blazor resources mentioned here. They will allow you to understand how to integrate authentication and authorization correctly. Furthermore, the Auth0 Templates for .NET package will allow you to have applications ready to use in minutes.

Leave your experience using authentication and authorization with Blazor in the comments.

Pushed Authorization Requests in .NET 9: Why and How to Use Them

Andrea Chiarelli — Wed, 15 Jan 2025 09:30:49 +0000

You may have heard that .NET 9.0 brings Pushed Authorization Requests (PAR) support in ASP.NET Core. If you are wondering what the heck Pushed Authorization Requests are, why you should use this feature, and how to use it in your .NET applications, well, this article is for you.

PAR enhances the security posture of your ASP.NET Core application that uses OpenID Connect and OAuth 2.0. You should care about this security improvement, especially if you build applications for the financial, healthcare, insurance, and other data-sensitive sectors, where it is a requirement.

Before you start, you need some basic knowledge about OpenID Connect and OAuth 2.0. You don’t need to be an expert; just a high-level knowledge of these protocols is enough to understand why and how PAR works.

The Basic OpenID Connect Flow

Let’s start by recalling how a basic OpenID Connect (OIDC) flow works. By basic flow, I mean a flow involving a classic server-rendered web application, i.e., in the context of .NET, a classic ASP.NET Core MVC application, a Razor Pages application, or a Blazor Server application. In the scenario involving this type of application, the flow we use is the Authorization Code flow, which we are going to describe using this diagram:

In the scenario illustrated by the diagram, we have:

A browser, which is the tool used by the user to access our web application.
The web application, called client application in the diagram because it’s a client of the authorization server in the OAuth 2.0 and OIDC context.
The authorization server, which is responsible for authenticating the user and authorizing the application.
The API server, which is the protected server our web application wants to access using an access token.

Following the numbered arrows, we can describe the flow as follows:

The user uses their browser to access the web application. The application finds that the user is not authenticated and builds an authorization request for the browser; then, it redirects the browser with this authorization request to the authorization server for authentication.
The browser sends the authorization request to the authorization endpoint of the authorization server, and the user authenticates. As a result of the authentication, the browser receives an authorization code from the authorization server.
The browser provides the authorization code to the web application.
The web application calls the token endpoint of the authorization server and provides the authorization code. As a response, the authorization server returns an ID and access tokens.
The web application uses the ID token to get information about the user and the access token to call the protected API.

This is a simplified description of the OIDC flow for authenticating the user and authorizing the web application to access the protected API server.

Using OIDC in ASP.NET Core

As you can see from the previous section, there are many moving parts behind the user authentication and application authorization with OIDC. In .NET, you don’t need to take care of all these details. What you usually need to do is to correctly configure the OpenID Connect middleware. In practice, the following code in your Program.cs file works the magic in the basic scenario:

builder.services.AddAuthentication(options =>  
  {  
 options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;  
 options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;  
  })  
 .AddCookie()  
 .AddOpenIdConnect("Auth0", options =>  
  {  
 options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";

 options.ClientId = builder.Configuration["Auth0:ClientId"];  
 options.ClientSecret = builder.Configuration["Auth0:ClientSecret"];  
 options.ResponseType = "code";  
});

The code snippet gets the configuration parameters of the authorization server — Auth0 in the example — from the appsettings.json file, or even better, from environment variables. You don’t need to do anything else to enable your web application to get the ID and access token. Everything happens behind the scenes!

Some Potential Issues

You probably already knew all this, but maybe you never wondered what problems can arise with this well-proven flow. There are two points in the OIDC flow that can have potential security and privacy issues, as highlighted in the following diagram:

The first point is when the web application redirects the browser to the authorization server to authenticate the user. The second point is when the browser calls the authorization endpoint of the authorization server. Both points are related to the authorization request prepared by the web application and sent by the browser to the authorization server.

The main issues that can affect the authorization request are:

The authorization request could be altered. Usually, the web application builds the authorization request on behalf of the browser and then redirects the browser to the authorization server. A malicious actor, such as a browser extension or malware, can modify, add, or remove one or more parameters of this request before sending it to the authorization server.
No guarantee of the request's provenance. As we said, the web application builds the authorization request on behalf of the browser. However, there is no guarantee that an authorization request was built by the web application. Anyone can build it once they know some basic data, such as the client ID and the redirect URI.
No guarantee of confidentiality. Although the browser sends the authorization request to the authorization server via HTTPS, the request parameters can be intercepted by third-party applications, such as proxies, load balancers, or even browser plugins. A malicious network component of this type can inject or change the request parameters, not to mention that the request itself can be logged.
Browser limitations. Finally, a very complex query string in the authorization request may incur possible browser limitations on URL length.

Entering Pushed Authorization Requests (PAR)

While the issues pointed out above may appear as non-crucial issues in ordinary authentication contexts, they become significant in contexts where privacy and data protection are paramount.

Here comes PAR, an extension of OAuth 2.0 (and then of OIDC) that enhances the protocol’s security level to solve those issues and protect the authorization request’s exposure.

We will not dive deep into the details of this extension. Read this article to learn more about how Pushed Authorization Requests work. Anyway, to have a high-level idea, let’s follow this new flow in this diagram:

As usual, the user accesses the web application with their browser.
The web application builds an authorization request, but this time, it sends the request to the authorization server using the new PAR endpoint instead of sending it to the browser. The web application uses the PAR endpoint to register the authorization request and get an identifier for this request (the request URI).
Instead of the typical authorization request, the browser will get a URL with the request identifier as a parameter. No risk of sensitive detail exposure or modification this time; just an identifier saying nothing to a potential attacker.
When the authorization server receives the request with the request URI from the browser, it retrieves the previously registered authorization request and processes it as if the browser sent it.
From now on, the usual flow continues.

PAR guarantees more security and confidentiality when managing authorization requests. It’s part of a set of specifications that fall under the umbrella of FAPI, an OpenID initiative that aims to strengthen the protocols to make them compatible with the more restrictive needs typical of financial, insurance, healthcare, and governmental contexts, among other contexts.

How to Use PAR in .NET 9

Now that we have an idea of what PAR is and how it works let's see how to use it in .NET 9.

To add PAR support to your ASP.NET Core application, your OIDC configuration in Program.cs should look like the following:

builder.services.AddAuthentication(options =>  
  {  
 options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;  
 options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;  
  })  
 .AddCookie()  
 .AddOpenIdConnect("Auth0", options =>  
  {  
 options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";

 options.ClientId = builder.Configuration["Auth0:ClientId"];  
 options.ClientSecret = builder.Configuration["Auth0:ClientSecret"];  
 options.ResponseType = "code";  
});

Can you see the difference with the code shown earlier? No? Can't you see it?

Actually there is no difference! .NET supports PAR by default, with a fallback to the traditional flow in case the authorization server does not support PAR. That’s amazing, don’t you? You get more security with no additional code.

You may say, “If I don’t need to add code, why should I care about PAR and how it works?” Actually, you should be aware of what happens under the hood. When things go wrong, having an idea of what is happening at a lower level can be helpful for debugging and detecting the cause of an issue.

Assume you are used to checking the traditional OIDC flow when a problem with authentication arises. You migrate your application to .NET 9 without any need to change code and everything works fine. One day you have a problem with user authentication and analyze the HTTP traffic to try understanding what’s going on, and you don’t find the classic authorization request. I bet you'll have a hard time figuring out what happened, since you didn't change your code.

If you were already prepared, you wouldn't have been surprised by this new flow.

Controlling PAR Configuration

We said that PAR is supported by default in .NET 9. But what if you don’t want to use it? How can you tell your application to just use the classic OIDC flow? You can do it as follows:

options.PushedAuthorizationBehavior = PushedAuthorizationBehavior.Disable;

The PushedAuthorizationBehavior option allows you to configure PAR behavior. In the previous example, you disable it, forcing your application to fall back to the classic OIDC flow. You can also force your application to use PAR with the following settings:

options.PushedAuthorizationBehavior = PushedAuthorizationBehavior.Require;

In this case, your application will use the PAR flow. If the authorization server does not support PAR, your application will not fall back to the classic OIDC flow but will throw an exception.

Finally, you can handle a new event, onPushAuthorization, to customize the authorization request before it is sent to the authorization server. The following example shows how you can create a handler for this event:

options.Events = new OpenIdConnectEvents  
{  
  OnPushAuthorization = async ctx =>  
  {  
    ...
  }  
};

Summary

We started by analyzing the basic OIDC flow and discovered a few possible security and privacy issues with authorization requests. Then, we introduced PAR and learned how it works. We also learned that .NET 9 introduces PAR support for ASP.NET Core applications by default without requiring us to write code. However, we can configure and customize PAR behavior programmatically by using a couple of options.

I hope you now have a clearer understanding of what PAR is, why using it, and how to use it in ASP.NET Core starting with .NET 9.0.

Sessions, Tokens, and Rock'n'Roll

Andrea Chiarelli — Sun, 19 Nov 2023 23:00:00 +0000

Does dealing with tokens eliminate the need for cookie-based sessions? You will find plenty of questions like this on Stack Overflow, reddit, and other developer communities. Very often, developers confuse sessions, cookies, tokens, and other similar concepts that are somewhat related to authentication and authorization. Let’s try to get some clarity.

Disclaimer: This is not a complete guide on sessions, cookies, and tokens. This is an attempt to clarify the basic concepts on which sessions, cookies, and tokens are grounded and dispel the most common misunderstandings on the topic.

What Is a Session?

Let's start by clarifying what a session is. A session is a sequence of interactions between a user or a client application and a server. A session starts with the initial interaction and lasts until explicitly closed or after a given period of inactivity. A session can also last indefinitely if no specific termination rule is defined.

Usually, sessions have an associated state containing specific data, for example, the user's name, email, and other data related to the current user's activity.

From a conceptual point of view, this is what you need to know about a session. But you may be thinking about how to implement it, and that's probably where the problems start.

Before moving on, let us point out that the implementation of a session depends on the specific communication protocol. In this article, only HTTP-based sessions will be addressed.

Sessions and Cookies

On the Web, a session is a sequence of HTTP requests from a client and related responses from the server. However, by design, each HTTP request is independent of all others. That means that the HTTP protocol itself can't keep information between requests. In other words, it's a stateless protocol. How can a server recognize that a group of requests is coming from a specific client? How can it maintain the state between independent calls? Here's where cookies traditionally come in.

Here are the cookies!

I guess you know what a cookie is. Either as a user or as a developer, you have dealt with them directly or indirectly. Although, as a user, you may dislike them for their sometimes intrusive use, as a developer, you may have appreciated their usefulness.

Often, the names assigned to these artifacts seem to attribute thaumaturgic properties to them: authentication cookies, tracking cookies, session cookies. But beyond that, a cookie is just a small block of data created by the server and stored on the client, your web browser. Nothing more. The information stored in the cookie makes it special.

Session cookies

The typical approach to building HTTP-based sessions is for the server to send the browser a cookie with a unique ID: the session ID. That cookie, which magically becomes the session cookie, will be sent back to the server with any subsequent request. This causes the server to finally recognize HTTP requests coming from the same client and thus making up a session. In addition, the server can use the session ID to store and retrieve data related to the current user's activity: that's how the session state is maintained!

Session cookies rely on the native ability of web browsers to manage them without the developer's intervention. Of course, they should have the HttpOnly and Secure attribute set, and other requirements must be met to ensure security, but this is beyond the scope of the topics to be discussed here.

The main takeaway is that cookies allow tracking clients' requests so that they can build a session with a state stored on the server side. Usually, the session cookie only contains the session ID value.

Pros and cons of cookie-based sessions

Now that you understand how cookie-based sessions work, let's summarize the main advantages and disadvantages of this approach.

Pros

Cookies are tied to a domain, that is, the browser sends them back only to the server that created them. They can be configured to be shared with subdomains, but by default, they can't be shared with other domains.
They require little storage on the browser. As a result, they have a low impact on the amount of data transmitted in each individual request.
They are automatically managed by the browser.

Cons

Without proper precautions, cookies can be exploited to perform CSRF and XSS attacks and improperly access active user sessions.
You may run into CORS problems when building apps across multiple domains.
They have a scalability problem. If you replicate the server to spread its high workload, you need to centralize the session state management. In fact, the server that receives a request with a cookie might be different from the server that generated it. This increases the complexity of each interaction.

Sessions and Tokens

Now you know that requests sent by a browser to a server are bundled into sessions using cookies. So far, so good!

But the Web is not just for browsers. Mobile and desktop clients, also known as native clients, can make HTTP requests as well. Leaving out clients that use an embedded browser to render web pages, native clients have no support for cookies. So the problem arises again: how do you build a session from a sequence of stateless HTTP requests? This is a job for tokens. 😎

Meet the token

Before going ahead to see how tokens can help you build HTTP-based sessions, let's try to understand what a token is. Generally speaking, "token" is an extremely generic term. However, in the context of this article, a token is just a string, a sequence of generated characters. In particular, it's a unique string that identifies requests coming from the same client.

What are you saying? Do you have the feeling of a deja vu? Well, actually, the basic idea of building sessions here is the same as the cookie-based one. The token value is the session ID. The native client must send it to the server along with each request.

Unlike the cookie case, however, you don't have a standard specification that tells you how to store and manage tokens. You can send them to the server as a header, in the query string, or in the request's body. You don't even have a standard tool that takes charge of automatically managing tokens, as the browser does with cookies. As a developer of the native application, it's your responsibility to take care of the tokens according to what the server expects. So, you have to store the token sent by the server somewhere in your application, maybe just keeping it in a variable, but possibly you would save it to storage. You have to add the token to each request sent to the server. If your application interacts with different servers, you have to take care to send the right token to the right server. In other words, you have to replicate much of the work that browsers automatically do with cookies.

On the server side, everything remains pretty similar to the cookie-based session management. The server maintains the session state, and the session ID is the key to retrieving it. The only difference is that the session ID is not passed in a cookie but is the token's value.

JWTs

The type of token described so far is what is known as an opaque token, that is, a token whose value has no specific meaning for the client application. But in the magical world of tokens, there are some "talking" ones, such as JSON Web Tokens (JWT). These are tokens containing encoded data that the client application can decode and read. This feature opens new horizons in session management: the inversion of state maintenance! Why keep the session state on the server if it can be kept on the application client?

Think about this for a moment. Keeping the session state on the server comes at a cost in terms of both storage and performance. Also, if the client needs certain information about the current session, for example, the user's profile or other technical data, it has to make calls to the server. Then there is the system scalability problem: if you replicate the server to spread its high workload, you need to centralize the session state management. In fact, the server instance that receives a request with a token might be different from the server instance that generated that token. Remember that this detail also applies to session cookies. In short, server-side session management is a bit of a hassle for the server.

JWTs can solve these problems. They encode into the token the information (or at least part of it) that the server would store in the session state. The client application will have the user's data and other stuff at its disposal as soon as the session starts and no longer needs to request them from the server for the duration of the current session. This frees some server memory and lightens its workload a bit.

Also, the application client sends the token back to the server when it makes a request. The server instance receiving that request will get the session state from the token, and the scalability problem is solved as well. That's fantastic! 🎉

JWTs and browsers

The good news is that JWTs are not specific to native clients. Web applications can also use them. You can use JWTs in your Single Page Application to lighten the server workload and promote server scalability.

Of course, you will need to do some additional work on your SPA's code. You have to decode the JWT and verify its signature to make sure it comes from the right server. You have to store it somewhere to prevent losing it after a page refresh. You also have to add the JWT to each request sent to the server and take care of sending the right token to the right server, in case you talk with multiple servers.

Wait! Isn't part of this stuff automatically handled by the browser when you use cookies? What about storing your JWT in a cookie? That's a great idea! You still have the session information at your fingertips and leverage the standard cookie behavior to handle the interaction with the server. Awesome! 🙌

While storing a JWT into a cookie allows you to delegate part of the token management to the browser, you should also consider cookies' disadvantages, as mentioned earlier.

Pros and cons of token-based sessions

Let's summarize the main benefits and drawbacks of using tokens to track your sessions.

Pros

Tokens are platform-independent: they can be used by web applications as well as native apps.
JWT tokens promote server scalability, since they can relieve the server of the responsibility of maintaining the session state.
Tokens can be saved in different types of storage: they can be stored in memory, in cookies, in the browser's session storage, or in native secure storage.

Cons

Tokens may be exposed to greater security risk since there are no standard protection mechanisms like those applied by browsers to cookies, and their management is left to the developer.
JWT tokens' size can become considerable if a lot of state information is maintained. This can affect the transmission of data to the server.
The server can't invalidate a JWT sent to the client, so its data can become outdated until a new request is made or the JWT expires.

ID Tokens and Sessions

Do you know the law of the hammer? It says that when you have a hammer, everything looks like a nail. Maybe that's what happens to some developers when they discover JWTs. Let me explain briefly.

When does a session start? Usually, after the first request is sent to the server. In its response, the server sends a brand new session ID (through a cookie or as a token), and everything begins.

And what is one of the most common first requests sent to a server by an application? An authentication request.

If your application uses OpenID Connect (OIDC) for user authentication, it will receive a JWT as a confirmation of successful authentication and, optionally, some data about the user. Can you consider this JWT a session token? If you are an OIDC-experienced developer, you know that the answer is "no!". But once I was asked by a developer: "Why do you still need cookies if you get a JWT from the authentication server?"

Let's clarify that the JWT sent by the OIDC provider is a token the named ID token, that has a very specific task: to prove that the user has been successfully authenticated. It's not meant for session management. You should still use cookies or yet another token to manage your application's session.

To learn more about the nature of ID tokens and their correct use, check out this article.

When your app receives an ID token, it knows that the user has been successfully authenticated, and it can start a session — but with its own session ID.

Session & session

Consider the following picture, which describes a common scenario involving OIDC authentication:

In this scenario, you have two active sessions:

The session with the OpenID Connect provider. This session starts with user authentication and tracks all interactions with the authentication server.
The session with your own server. This session starts when your application receives the ID token and tracks all the interactions with your own server.

What is the relationship between the two sessions?

They are largely independent of each other. If the session with your own server expires or is closed, all the data related to this session should be destroyed, including your ID token. However, the end of your session normally has no effect on the session with the OIDC provider. It can continue to be alive. This can be convenient because it allows the user to log back in to your app without having to re-enter their credentials as long as the session with the OIDC provider is active.

What happens if the session with the OIDC provider expires? As said before, the two sessions are independent of each other so, in practice, nothing happens to your server's session, unless you have specific requirements. In this case, you have to look for a solution to keep the two sessions in sync.

Remember, your ID token has nothing to do with your session apart from telling you that you can start it.

Access Tokens and Sessions

In the OAuth 2 context, access tokens allow a client application to access a resource, such as an API, on behalf of the user.

To learn more about access tokens and the difference with ID tokens, check out this article.

In a client-server interaction, access tokens are credentials indicating that the client application is authorized to send requests to the server. Fundamentally, they have a different role from a session token. That is, their job is not to keep track of requests made by the same client and possibly enable session state management.

Analogies with session tokens

Within certain limits, however, the use of an access token can resemble that of a session token. It is sent to the server with each request and the server uses it to retrieve information about the permissions granted to the client for this set of interactions. This is true both when the access token is an opaque token and when it is a JWT. Note the analogy with session state retrieval described earlier.

Differences from session tokens

Unlike session tokens, the information represented by access tokens is critical to client and server security. One strategy to mitigate the risk of theft and unauthorized use of an access token is to reduce its validity to a limited time.

Of course, this contrasts with the classic concept of a session as the set of potentially infinite interactions between the client and the server. However, the access token expiration must necessarily result in the current session's termination: the current token is no longer valid, and the user must authenticate again to obtain another access token for the client application. This would mean starting a new session.

Fortunately, OAuth2 provides refresh tokens, that is, tokens designed to renew an expired access token without user intervention. They provide a compromise between security needs and user experience.

To learn more about how refresh tokens work, read this article.

In addition, access tokens and refresh tokens can be used even when the user has no current active session. This is the so-called offline access mode. Think of an application that sends tweets or emails on your behalf on a scheduled basis: once you authorize it, you don't need to have an active session on that app when the scheduled job is triggered.

These features highlight how an access token does not have the typical characteristics of a classic session token. Its value is not simply a mechanism for grouping calls to a server and retrieving information related to user activity. It serves a very different purpose.

What About Rock’n’Roll?

If you reached this section, you have learned a lot about sessions, cookies, and tokens.

At this point, you may be wondering: what does rock'n'roll have to do with this? Well, to tell you the truth, it only served to... set the tone for the title of the article.

But in fact, there is some relevance. The interactions between a client and a server, the going back and forth between the two actors somewhat reminds of a kind of dance. Incidentally, the interactions between the client and the OIDC provider for user authentication are sometimes called the authentication dance. It may not be quite rock'n'roll, but it is still dancing. 💃🕺🏻

Summary

In this journey, you explored the session concept in the HTTP context and how it can be implemented using cookies or tokens. Beyond the main pros and cons that each approach brings, you learned how having a token does not mean that it necessarily has anything to do with session management. The case of ID and access tokens is an example: each of them has its own specific role in authentication and authorization.

Auth0 Templates for .NET

Andrea Chiarelli — Tue, 12 Sep 2023 08:47:46 +0000

If you are a .NET developer and have been using Auth0 by Okta's authentication and authorization services, chances are that you've come across one of my articles. 😎

Over the past few years, I have tried to explain in simple and, most importantly, practical terms how to integrate Auth0 into the various types of applications you can build with .NET. My goal has been to simplify the experience of .NET developers approaching Auth0.

The topic of authentication and authorization is complex, and untangling the details of protocols like OIDC and OAuth2 is not easy. Fortunately, SDKs provide a great deal of help in abstracting the complexity inherent in the protocols. But even knowing which SDK to use based on the type of application and how to write the code to integrate Auth0 when an SDK is not available requires some familiarity with both the Auth0 product and the infrastructure provided by .NET.

Here are the Auth0 Templates for .NET!

To simplify the development experience for .NET developers, I tried to go beyond creating tutorials and started the Auth0 Templates for .NET project, a package of .NET project templates with everything needed to support Auth0's authentication and authorization services! 🎉

For your next .NET application using Auth0, you only need to select the right template and provide the configuration parameters from the Auth0 dashboard. You can even not provide the configuration parameters if you have the Auth0 CLI installed on your machine. But let's go one step at a time.

First, you need to install the NuGet package. You can do this by running the following command in a terminal window:

dotnet new install Auth0.Templates

Once the package is installed, you will have six templates to create your own applications:

Auth0 MVC Application
Auth0 Web API Application
Auth0 Blazor Web App
Auth0 Blazor Server Application
Auth0 Blazor WebAssembly Application
Auth0 MAUI Application

The project is a work in progress, and more templates will be added in future releases.

Create your Auth0-enabled .NET Project with the .NET CLI

You can use these templates from the command line, through the .NET CLI, or in Visual Studio.

Say you want to create a new Blazor Server application that uses Auth0 as its Identity provider. The first step is to register your app with Auth0. During this first step, you will get some settings that you will use to set up your app through the templates.

Then, on your machine, run the following command in a terminal window:

dotnet new auth0blazorserver --domain <YOUR_AUTH0_DOMAIN> --client-id <YOUR_CLIENT_ID> -o MyBlazorApp

You specify the auth0blazorserver template as the template to use. Then, you pass your Auth0 domain and your client ID, values that come from the registration step. Finally, you indicate the folder where the new application will be created.

Voila! After a few seconds, you will find a new Blazor Server project in the folder you specified with all the code to support authentication via Auth0! 🪄

Add the power of the Auth0 CLI

If you have the Auth0 CLI installed on your machine and logged in to your Auth0 tenant, you can even skip the registration step. You can simply run the following command:

dotnet new auth0blazorserver -o MyBlazorApp

The Auth0 CLI will automatically register you application with Auth0 and configure it on your behalf. You can have a working .NET application in less than a minute! :🧞‍♂️

Create your Auth0-enabled .NET Project with Visual Studio

If you prefer to use Visual Studio, you just need to select the Auth0 template from the list, as shown below:

Then, provide the required settings as shown in the following picture:

Unfortunately, due to a Visual Studio limitation in running external script, you can't leverage the Auth0 CLI magic to automatically register your application in this case.

You can also use the templates in Visual Studio for Mac and JetBrains Rider.

Stay Tuned!

I'd like the Auth0 Templates for .NET project to become the starting point for building any .NET application with Auth0 embedded. I plan to add more templates and improve the developer experience in the near future.

Give it a try and let me know what do you think. Your feedback is welcome, as well as your contribution. 🙏