Duende Blog

Protocols don't die; they accumulate gravity. Every integration, every compliance mandate, every federated trust relationship adds mass. SAML has been accumulating gravity for over twenty years, anchoring identity federation across enterprises, governments, universities, and healthcare systems worldwide. Dismissing it as "legacy" is a misreading of how protocol ecosystems actually work. SAML isn't fading. It's entrenched. Understanding why it endures is essential for anyone building identity infrastructure that operates in the real world.

This post traces SAML from its origins in the early 2000s through its current role in the identity landscape, and looks ahead to where the protocol is going — not as a replacement story, but as a coexistence story.

Back in early 2020, Dominick Baier, one of Duende’s founders, wrote a provocative post titled "SPAs are dead!?" that sent ripples through the identity community, warning of stricter cookie handling to come. At the time, Safari's Intelligent Tracking Prevention had begun blocking third-party cookies, Brave followed suit, and Chrome had announced vague plans to do the same "by 2022." The question on every developer's mind was whether these changes would fundamentally break how single-page applications handle authentication.

The answer, we now know definitively, is yes. Yes, they did. The Cookie Apocalypse already happened, and every SPA needs a BFF (Backend for Frontend).

Let's take a look at why that happened, and how it happened.

It's 2 AM, and your cellphone begins to vibrate off the nightstand. It's your CEO. Picking up, while still in a daze, they frantically speak the words, "The business is down! We need your help." It's not a database issue, or a DNS issue; it's much worse: it's an identity issue. Every microservice that depends on token validation is failing. Your API gateway can't verify JWTs. Your users can't log in. Your partners can't access your APIs. It's everything.

What a moment to learn that identity was never "just a feature," it was infrastructure all along.

Too many engineering organizations still treat authentication and authorization as a checkbox item — something you bolt on during a sprint or two, drag the issue into the "completed" column, and then forget about it. But identity touches every service, every API boundary, every user interaction, and every compliance audit. When it breaks, nothing works. When it's fragile, everything is fragile. The teams that internalize the practice of treating identity with the same rigor they give to databases, networking, and observability ship faster and recover from incidents more quickly. By prioritising identity as core infrastructure, teams spend far less time firefighting security issues and more time building.

This post makes the case for treating identity as first-class infrastructure, explores what that means in practice, and connects it to the broader industry shift toward Zero Trust architecture.

A well-tested codebase is the foundation of confident software delivery. Yet anyone who has written tests for complex scenarios knows the pain: any number of Assert.Equal calls, each one a liability waiting to break when a property name changes or when you add a new field. Finding better ways to assert our software's behavior is an ongoing pursuit for all of us, and that pursuit led us to this quarter's Duende Open Source Sponsorship recipient: Verify.

In our fifth sponsorship, the team at Duende has chosen Verify as the next open-source recipient of our commitment to supporting projects that empower individuals, teams, communities, and organizations.

Now let's see what Verify is all about.

When a user signs in to an application, their Identity Provider (IdP) provides metadata about the user’s identity. This static information was provided by the user when the account was created, like the user’s name, email address, and country of origin. The amount of data available depends on the IdP implementation and requirements. Based on the requested (and consented) scopes, the IdP provides some or all of this information as claims to the client application.

The default mechanism that Duende IdentityServer uses for storing claims containing user information is a client-side cookie. Too much information bloats the cookie, increasing the size of each request and degrading performance. Additionally, the web client is storing access tokens in the browser, which goes against today’s best practices (e.g., using Backend-for-Frontend). We can work around these issues by storing the cookie data on the server using Duende IdentityServer server-side sessions.

If you've used an AI coding assistant with Duende IdentityServer, you've probably noticed the responses sometimes veer off track. Ask how to configure refresh token rotation, wire up a federation gateway, or set up DPoP, and you'll get a response that's almost right. The general shape of correctness is there, but the ASP.NET Core and Duende-specific details are either missing or subtly wrong. Why is that? General-purpose models don't have deep expertise on identity protocols and Duende-specific configuration.

Identity is a domain where "close enough" isn't good enough. How do we solve this critical problem while helping you build secure solutions? We set out to build two complementary tools to close the gap: Duende Agent Skills and the Duende Documentation MCP Server.

Skills are static files that give your AI assistant structured domain knowledge: they help it know what to do. The MCP server is a local process that provides search and retrieval tools against our documentation, blog, and sample code. The MCP server helps the assistant look things up. You can use either or both. They're independent and complementary.

When you separate identity management from your application, login is handled through OpenID Connect. But what about registration? A community discussion recently highlighted a common scenario: you want a "Register" link in your application that takes users straight to a registration page on Duende IdentityServer, skipping the login screen.

OpenID Connect has a standardized answer for this. Initiating User Registration via OpenID Connect 1.0 defines a prompt=create parameter that tells the identity provider to show account creation instead of login. Duende IdentityServer has supported this since version 6.3. Let's look at the spec and then walk through how to implement it with Dudende IdentityServer.

If you have spent any time writing ASP.NET Core security code, you have probably written something like this more than once:

var sub = User.FindFirst("sub")?.Value;
var isAdmin = User.HasClaim("role", "admin");
var scopes = User.FindFirst("scope")?.Value?.Split(' ') ?? [];
var hasInvoiceRead = scopes.Contains("invoice.read");

Nothing is technically wrong here, but the problems add up. The claim type strings "sub", ClaimTypes.Email, and "scope" are scattered across controllers, middleware, and authorization handlers. Every call site has to remember to null-check. When a claim name changes, you search and replace across the whole project and hope you caught everything. The code reads like plumbing rather than intent.

C# 14, shipping with .NET 10, introduces extension members: a language feature that lets you attach properties (not just methods) to existing types. Applied to ClaimsPrincipal, it gives you a clean, centralized place to put all of that claim-access logic, with zero runtime overhead.

In regulated industries like finance and healthcare, "knowing what happened" is often just as critical as preventing bad things from happening. Frameworks like SOC 2 and HIPAA don't just ask you to secure your systems; they ask you to prove it. That means structured, queryable, tamper-evident records of security events: who logged in, when a token was issued, which client authenticated, and what failed.

Standard application logs aren't built for this. They're noisy, unstructured, and designed for developers to debug issues. But not for reviewing access patterns across six months of production traffic.

Duende IdentityServer ships with a structured eventing system that addresses this gap directly. Architecturally, this means a clean separation between high-volume operational logs and the dedicated, low-volume security events that form the official record.

In this post, we'll walk through how you, as a developer, can use Duende IdentityServer's events to build an audit trail that satisfies compliance requirements in Highly Regulated Industries (HRI).

On March 10, 2026, Microsoft disclosed CVE-2026-26127, a high-severity denial-of-service vulnerability in the Microsoft.BCL.Memory NuGet package. It can be triggered when decoding malformed Base64Url input.

Because several Duende packages depend on this package transitively, your builds may now show NuGet vulnerability warnings. We've shipped patch releases across our library stack to resolve this. Here's what you need to know.