Duende Blog

"Just use OIDC" is the most common incomplete advice in identity. It sounds reasonable. OIDC is newer, simpler, better for APIs and mobile, and backed by a specification that developers actually enjoy reading. But advice that ignores the world as it exists is not the best advice. The world has SAML everywhere: in enterprise SSO, in government federation, in healthcare identity, in academic research networks. OIDC does not replace that. It complements it. And the identity architectures that actually work in production — the ones that serve real organizations with real compliance requirements — speak both protocols.

This post dismantles the "SAML vs. OIDC" framing, makes the case for coexistence, and shows how a dual-protocol identity provider eliminates the false choice between modern and established.

SAML 2.0 has been an OASIS standard since 2005, and it still underpins federated single sign-on across enterprise, government, healthcare, and education. The specification is large, but the components that matter in practice are finite. Here are the nine you need to understand, ordered from most to least critical.

Bearer tokens are simple. PKCE is easy to skip. Pushed Authorization Requests feel like overhead. Everything works fine, right up until it doesn't. And when it doesn't, the costs aren't measured in engineering hours. They're measured in regulatory fines, breach notifications, and headlines that make customers look for alternatives.

Most teams evaluate security upgrades by asking what they cost. The better question is what it costs to skip them.

In a shared-issuer model, every tenant's tokens are signed with the same cryptographic key. One compromised key compromises everyone. Every tenant. Every token. Every session. In regulated industries like financial services, healthcare, government, and enterprise SaaS, this is not a theoretical risk. It is a finding on an audit report, a red flag in a SOC 2 examination, and a deal-breaker in a procurement security review.

Token issuer isolation changes the equation. Each tenant gets its own signing keys, JWKS endpoint, and token validation chain. A key compromise in one tenant stays contained to that tenant. In other words, token issuer isolation is the control that determines whether a key compromise is a catastrophic breach or a contained incident.

This post explains what issuer isolation means in cryptographic terms, why it matters for SOC 2 and ISO 27001, and how Duende IdentityServer 8 implements it without adding to your operational burden.

There's a familiar pain point in enterprise software: you need one capability from an identity platform, but to get it you have to adopt the entire platform. You wanted SAML federation for a single enterprise customer, and now you're running a full Identity Access Management (IAM) suite with user management, workflow engines, and admin portals you'll never use. You're paying for it in licensing, complexity, operational overhead, and the attack surface you didn't ask for.

This is the monolith problem.

The software industry spent the last decade decomposing monolithic applications into modular, composable services. Gartner formalised this as the "composable business." Organisations built from interchangeable building blocks that can be assembled and reassembled as needs change. Martin Fowler's work on microservices laid the architectural foundation for how teams think about modularity. But somehow, the identity layer got left behind. Most IAM platforms are still monoliths: all-or-nothing, take-it-or-leave-it.

The composable identity pattern offers an alternative. Start with the core protocol support you need today. Add capabilities incrementally as your business demands them. Never pay the complexity cost of features you don't use. This post explains the pattern, shows what it looks like at each stage of a company's growth, and demonstrates why additive architecture is the future of identity infrastructure.

Acquisitions happen. Product lines multiply. Regional regulations demand local branding. A hotel group operates three chains, each with its own loyalty program and login experience, but a single backend manages them all. A media company owns four publications, each with its own subscriber identity, but a single account should let a reader access all four. A European expansion forces your US-branded product to present a different legal entity and a different login page in Germany.

In all these cases, the underlying identity infrastructure is shared: the same user store, the same authorization logic, and the same deployment. But the face presented to the user must be distinct.

This is not a CSS theming problem. It is an identity architecture problem.

Each brand needs its own token issuer, discovery endpoint, signing keys, and UI. Multi-issuer support in Duende IdentityServer v8 makes this possible without duplicating infrastructure, giving every brand full cryptographic and experiential independence from a single deployment.

Quantum computers capable of breaking RSA and elliptic-curve cryptography don't exist yet, but the threat is real enough that NIST finalized three post-quantum cryptography (PQC) standards in 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). The concern isn't just future decryption. "Harvest now, decrypt later" attacks mean that encrypted data captured today could be broken once quantum hardware catches up.

.NET 10 ships first-class support for all three FIPS-standardized PQC algorithms, plus a hybrid approach called Composite ML-DSA that combines classical and post-quantum signatures. No hand-waving. Let's write code.

You need a property that validates its input. In C# 13 and earlier, that means writing a private backing field, a get accessor that returns it, and a set accessor that validates the value before storing it. Three moving parts for one property:

public class Greeting
{
    private string _msg = "Hello";

    public string Message
    {
        get => _msg;
        set => _msg = value ?? throw new ArgumentNullException(nameof(value));
    }
}

One property, one validation rule, three lines of ceremony. The backing field _msg exists only to give set something to write to and get something to read from. It carries no meaning of its own.

Multiply this across a configuration class with five or six validated properties, and the noise adds up fast.

Imagine a development team starting to build their own auth system from scratch. Talented developers, clean architecture, all the right OAuth 2.0 flows. When they succeed, they are proud of it, and they should be, because it works.

Months later, three sprints deep into adding SAML for a single enterprise customer. Their best Auth engineer had just given two weeks' notice. The compliance team is asking questions about session management that no one else on the team can answer. And the original six-week project? It had quietly become the single largest line item in their technical debt backlog.

"We'll just build it ourselves" is one of the most common and most expensive sentences in software engineering. The logic seems sound on the surface. Your team knows your requirements. You don't want vendor lock-in. You've got talented people. A few sprints, maybe a quarter, and you'll have exactly what you need.

Here's the thing nobody tells you during that planning meeting: the initial build is the cheap part. It's the years that follow — maintenance, security patching, protocol updates, compliance audits, incident response, and the features you didn't know you'd need — that quietly bleed budgets. And when things go truly wrong, the costs aren't measured in sprints. They're measured in breach notifications and lost customer trust.

This post breaks down the real total cost of ownership for identity systems, using data from the IBM/Ponemon Cost of a Data Breach Report and the Verizon DBIR. We'll be fair about when building makes sense. But we'll also make the case for a third option that most teams don't consider early enough, and it's where the smartest ones tend to end up.

Back in 2019, Dominick Baier, Duende Cofounder and Security subject-matter expert, wrote a prophetic post called "Two is the Magic Number", a riff on De La Soul's "Three is the Magic Number", arguing that you only needed two OAuth flows to cover every real-world scenario. At the time, it was a bold simplification. OAuth 2.0 had shipped with a sprawl of grant types: Implicit, Resource Owner Password Credentials, Authorization Code without PKCE, Client Credentials, and the ecosystem dutifully built tutorials for all of them. The result was confusion. Developers picked the wrong flow, shipped insecure apps, and blamed OAuth itself for being "too complicated."

Dominick was right, and the standards body agreed. OAuth 2.1 formally removed the footguns, mandated PKCE on every authorization code grant, and left us with a protocol that is dramatically simpler to learn and harder to misuse. If you're building on .NET 10 in 2026, this is the only article you need. Two flows cover almost everything. A third handles the edge case. Let's go.