SAML and OpenID Connect (OIDC): Coexistence, Not Competition

"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.

A Fair Comparison

Both SAML 2.0 and OpenID Connect solve the same fundamental problem: federated authentication. A user authenticated by one party needs to be recognized by another. Both protocols define how to represent that authentication event and transmit it securely. But they were designed for different eras and different ecosystems, and their strengths reflect those origins.

SAML 2.0, ratified by OASIS in March 2005, was built for a world of enterprise middleware and XML web services. Its strengths are real: a rich metadata model that enables automated trust establishment between organizations, comprehensive attribute-based access control, a detailed Single Logout specification, and deep support across every major enterprise IdP and SaaS application. SAML is governed by OASIS, a mature, vendor-neutral standards body, and has been battle-tested in production for over twenty years. Its weaknesses are equally real. XML is verbose and harder to debug than JSON. The full SAML 2.0 specification set spans thousands of pages. There is no native support for mobile apps or single-page applications. API authorization is entirely outside its scope. Developer experience with XML namespaces, canonicalization, and signature validation is challenging.

OpenID Connect Core 1.0, ratified in February 2014, was built on OAuth 2.0 for a world of mobile apps, REST APIs, and JSON-native systems. It is lightweight, developer-friendly, and works naturally with modern application architectures. OIDC supports mobile apps, SPAs, server-side apps, and CLI tools. Dynamic discovery and client registration simplify onboarding. Active specification development continues to extend its capabilities with CIBA, Rich Authorization Requests, and DPoP. Its weaknesses center on enterprise maturity. The OIDC Federation specification is still gaining adoption and does not yet match SAML's established trust model for large-scale interfederation. Enterprise entrenchment, while growing, has not displaced SAML in many sectors. And the OAuth 2.0 foundation, while powerful for API authorization, adds complexity for pure authentication use cases.

Neither protocol is universally better. Each dominates in the scenarios it was designed for.

The comparison table reveals a pattern rather than a winner. SAML excels in organizational trust at scale. OIDC excels in developer experience and in supporting modern applications. These are complementary strengths, not competing ones.

Why You Need Both: The Protocol Matrix

A single organization can easily find itself in a position where different parts of its infrastructure need different protocols. This is not a sign of technical debt or poor planning. It is the natural consequence of operating in a world where partners, regulators, developers, and end users each have different requirements.

Consider the protocol matrix:

Most organizations above a certain size have scenarios in multiple rows. An enterprise SaaS product that serves both consumer and corporate customers will have OIDC-based social login for consumers and SAML-based SSO for enterprise accounts, in the same product, serving the same application. A university research platform will use SAML for InCommon federation and OIDC for its mobile companion app.

The fallacy of protocol purity — choosing one protocol and refusing the other — limits your reach. Your enterprise customers need SAML. Your mobile app needs OIDC. Your API needs OAuth 2.0 access tokens. You do not get to pick one.

The cost of not supporting both is concrete. Enterprise deals are lost when a prospect requires SAML, and you only offer OIDC. Complex workarounds emerge when teams stand up a separate SAML-to-OIDC gateway as a side service, adding operational overhead and new failure modes. Managing two separate identity systems instead of one doubles the maintenance burden without doubling the capability. The pragmatic answer is a single identity provider that speaks both protocols natively.

Protocol Bridging: Your IdP as the Translation Layer

Protocol bridging means a single identity provider can accept authentication in one protocol and issue assertions or tokens in either protocol. The IdP becomes the translation layer between the SAML and OIDC worlds. From the user's perspective, they log in once. The protocol negotiation is invisible. This is the entire point.

The architecture looks like this:

flowchart TD
    A[Enterprise Partner<br/>SAML IdP] -->|SAML Assertion| B[IdentityServer<br/>SAML Consumer + OIDC Provider]
    B -->|OIDC tokens| C[Your Mobile App]
    B -->|SAML assertions| D[Partner's Legacy System]

A user at an enterprise partner authenticates through their corporate identity provider via SAML. IdentityServer consumes that SAML assertion, establishes a local session, normalizes the identity claims, and then issues OIDC tokens to your mobile app or SAML assertions to a downstream partner system. The consuming applications do not know or care which upstream protocol was used.

This bridging requires careful mapping of claims and attributes. SAML attributes and OIDC claims use different naming conventions, different data types, and different structural assumptions. A SAML attribute like urn:oid:0.9.2342.19200300.100.1.3 maps to the OIDC claim email. The attribute urn:oid:2.5.4.42 becomes given_name. The attribute urn:oid:2.5.4.4 becomes family_name. An identity provider that bridges protocols must handle this translation correctly and consistently.

Session management across protocols adds another dimension. When a user authenticates via SAML and then accesses OIDC-protected resources, session state must be coherent. Logout must propagate across protocol boundaries: a SAML LogoutRequest from the enterprise partner must terminate the local session and trigger OIDC back-channel or front-channel logout to all connected relying parties. Getting this right requires the identity provider to maintain a unified, protocol-agnostic session model internally, even as it speaks protocol-specific languages externally.

The Recommended Architecture: OIDC-First, SAML for Critical Partners

The most effective dual-protocol architecture follows a clear principle: use OIDC for everything you can, and SAML only where you must.

OIDC should be your default choice. For all applications you control — your mobile apps, SPAs, microservices, and APIs — use OIDC. It's simpler, more secure by default, and designed for modern architectures. JSON and JWTs are easier to debug than XML assertions. Discovery endpoints eliminate manual configuration. PKCE protects mobile flows. Refresh tokens give you fine-grained session control. Your development teams will be more productive, and your applications will be more maintainable.

SAML is for external federation with partners who require it. When your enterprise customer says "we only support SAML for SSO," you support SAML for that integration. When a government agency mandates SAML via FedRAMP or FICAM, you implement SAML to meet that compliance requirement. When an academic partner requires SAML to participate in InCommon or eduGAIN, you provide a SAML endpoint. SAML is a concession to reality, not a design preference.

The architecture looks like this: IdentityServer issues OIDC tokens to your ecosystem of applications. It presents SAML endpoints to the subset of partners who need them. Internally, you run a modern identity platform. Externally, you adapt to whatever protocols your partners require. The protocol becomes an adapter layer rather than a core design choice.

Start with OIDC. Add SAML only when a specific partner or compliance requirement forces your hand. Don't adopt SAML because it "feels more enterprise" or because you've heard it's required for B2B. Most modern B2B integrations use OIDC perfectly well. Use SAML only where it's actually required.

Real-World Example: Dual-Protocol in a SaaS Product

Consider a project management SaaS product that serves both consumer and enterprise customers.

On the consumer side, users sign up with email and password or authenticate via social providers like Google or GitHub through OIDC. The mobile app uses OIDC with PKCE for native authentication. The web SPA authenticates via OIDC and uses OAuth 2.0 access tokens to call backend APIs. Everything is JSON, JWTs, and REST endpoints.

On the enterprise side, corporate customers want their employees to authenticate through their existing identity provider, which is Okta, Entra ID, Ping Identity, or another enterprise IdP. The integration is SAML-based because the enterprise IT team's playbook says SAML. Trust is established through SAML metadata exchange. Attributes from the corporate directory (department, role, employee ID) are mapped to application-level claims that drive authorization decisions.

The identity provider sits in the middle and normalizes everything. Regardless of whether a user authenticated via SAML from their corporate IdP or via OIDC from Google, the identity provider produces a common internal representation. The SaaS application receives OIDC tokens and never needs to know which upstream protocol was used. Authorization logic, user profiles, and session management work identically for both user populations.

The operational requirements differ by protocol. SAML integrations require certificate management: signing and encryption certificates, along with rotation schedules, that must be coordinated with partners. OIDC integrations require key management through JWKS endpoints and automated key rotation. Monitoring must cover both protocol flows for errors and latency. Audit trails must span protocol boundaries so that a security investigation can trace a session from SAML authentication through OIDC token issuance without gaps.

How IdentityServer Handles Dual-Protocol Scenarios

Duende IdentityServer provides SAML 2.0 Identity Provider support alongside its OIDC and OAuth 2.0 capabilities, enabling dual-protocol scenarios from a single deployment. There is no separate product, no external gateway, and no middleware layer.

The SAML IdP capabilities include issuing SAML 2.0 assertions to registered Service Providers, generating SAML metadata at the /saml/metadata endpoint for automated trust establishment, supporting both SP-initiated and IdP-initiated SSO, handling Single Logout with front-channel notifications, and providing configurable assertion signing and encryption per Service Provider.

Each SAML Service Provider is configured with its entity ID, assertion consumer service URLs, signing and encryption certificates, and claim mappings. The SamlServiceProvider model supports per-SP customization of signing behavior (via SamlSigningBehavior), NameID format, encryption settings, and attribute release policies.

For the SAML consumer role (accepting assertions from external identity providers), IdentityServer leverages ASP.NET Core's external authentication pipeline. Third-party SAML authentication handlers integrate as external login providers, and IdentityServer's external authentication flow maps external SAML claims to internal user identities. This means consuming SAML from upstream and issuing OIDC tokens downstream is a supported architectural pattern.

The claim transformation pipeline is central to dual-protocol operation. The ISamlClaimsMapper interface allows custom mapping from internal claims to SAML assertion attributes. Default mappings handle common cases (name, email, role), while per-SP ClaimMappings provide fine-grained control. On the OIDC side, the standard IProfileService handles claim issuance. Both pipelines draw from the same internal identity representation, ensuring consistency across protocols.

Session management is unified. A single user session spans both protocols. A user who authenticates via an external SAML provider receives a local session that can serve OIDC token requests and SAML assertion requests alike. Logout propagates across protocol boundaries: IdentityServer's SAML Single Logout implementation coordinates with OIDC back-channel and front-channel logout to ensure all connected relying parties are notified, regardless of their protocol.

Conclusion

The "SAML vs. OIDC" framing is a false binary. Real identity architectures need both. Protocol selection should be driven by integration requirements, not by developer preference. Use OIDC where it fits best. Use SAML where it is required. Use both where the situation demands it.

A dual-protocol identity provider eliminates the false choice. It lets you serve enterprise SAML customers and modern OIDC applications from a single platform, with a unified session model, consistent claim handling, and coordinated logout across protocol boundaries.

The future of identity is not one protocol winning and the other losing. It is identity providers becoming protocol polyglots that translate between worlds, making the protocol an invisible implementation detail rather than an architectural constraint.

To see how Duende IdentityServer implements dual-protocol support with unified sessions and consistent claim handling, explore the SAML documentation.