Duende Blog

On April 21, 2026, Microsoft disclosed CVE-2026-40372, a high-severity vulnerability in the Microsoft.AspNetCore.DataProtection NuGet package. It allows attackers to execute an Elevation of Privilege attack by forging authentication cookies.

None of the Duende packages have a direct or transitive dependency on the Microsoft.AspNetCore.DataProtection NuGet package. However there are cases where you may be using that NuGet package as a dependency within your application.

When OAuth 2.0 was published as RFC 6749 in 2012, it was deliberately silent on the format of access tokens. The spec described them as opaque strings: the client receives one, attaches it to API requests, and never looks inside. That abstraction was intentional, but it created a vacuum.

As the industry adopted JWTs for access tokens (a practice accelerated by the publication of the JWT specification itself as RFC 7519 in 2015), every identity provider filled that vacuum in its own way. Auth0 puts scopes in an array. Azure AD used roles claims and application ID URIs. IdentityServer emitted individual scope claims. Okta had its own structure. The token was always a JWT, but beyond that, nothing was consistent.

The consequences were predictable. If you built an API that consumed tokens from a single provider, you wrote validation logic tailored to that provider's JWT structure. If your organization then migrated providers, or if you needed to accept tokens from multiple issuers (a common scenario in B2B integrations and microservice architectures), you had to write custom parsing logic for each one.

Claim names varied. Scope formats clashed. Some providers included an audience claim; others didn't. Some set a typ header; most left it as the default JWT. Every integration was a bespoke affair, and every bespoke affair was a surface for security bugs.

RFC 9068, published in September 2021, ended the guesswork. It defines a concrete JWT profile for OAuth 2.0 access tokens: which claims must be present, how they're formatted, and how validators should process them. It gives us a common language. When your identity provider issues an RFC 9068-compliant access token and your API validates one, both sides agree on the structure: the typ header reads at+jwt, the scope claim is a space-delimited string, the aud claim names the intended API, and so on. The timeline from silence to standard took nearly a decade: OAuth 2.0 in 2012, JWT in 2015, the draft profile in 2019, and the finalized RFC in 2021.

Today, every major identity provider supports it, and there is no longer a good reason to invent your own access token format.

Let me guess how this goes. You build a login page. You wire up registration. You hash passwords, set up MFA, ship it, and move on to the features that actually make your product interesting. Then, three months later, someone from legal walks over (or pings you on Slack, because nobody walks anywhere anymore) and asks: "Can you show me an audit trail of every admin action on user accounts for the last 90 days?"

And you stare at your screen, because you don't have one.

I have been that developer. Most of us have. Identity governance sounds like something that belongs in a compliance PDF, not in your sprint backlog. But here is the thing: when a regulation says "immutable audit trail," a developer writes that code. When GDPR says "consent must be versioned, purpose-specific, and withdrawable," a developer designs the schema accordingly. When data residency rules say "EU user data stays in the EU," a developer builds that routing logic.

Governance is a development problem. And if you are building a user management system, the checklist below is what separates you from a very uncomfortable audit.

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.

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.

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.

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.