The enterprise technology industry has been here before. SHA-1 certificate deprecation and TLS 1.0/1.1 removal were both deferred across the industry until browser vendors coordinated hard deadlines that made non-compliance a user-visible problem rather than a future risk. The organizations that treated those transitions as somebody else’s future problem were the ones scrambling when the deadline arrived. The technology to migrate had existed for years. The pressure to act had not.

What distinguished the transitions that went well from the ones that did not was whether the migration path was built into the technology itself. SHA-2 and SHA-1 could coexist during transition because PKI clients and certificate chains could tolerate mixed algorithm use while issuers, subscribers, and relying parties moved on different schedules. The transitions that succeeded with the least disruption were the ones where parallel operation was possible: old trust and new trust recognized simultaneously, with a defined handoff point rather than a hard cutover.

SAML is approaching a version of that deadline, and the migration path does not yet exist in standardized form. A SaaS vendor may have hundreds of enterprise SAML customers: some using persistent NameIDs, some using email addresses, some using custom attributes, some depending on IdP-initiated launch, and many relying on undocumented group-to-role mappings. The vendor can add OIDC for new customers, but it cannot simply switch existing tenants without risking duplicate accounts, broken administrator access, and failed audits.

That is the core problem: identity contract continuity. The hard part is not adding another login protocol. It is proving that the new OIDC relationship is the successor to the old SAML federation without changing the subject, audience, attribute, or authorization semantics the application already depends on.

I have been working on a draft specification, the OpenID Connect Migration Profile for SAML 2.0 Service Providers, to address that directly. It is now part of a broader set of interoperability profiles for SAML and OpenID Connect coexistence, because migration in practice is never a single hard cutover. This post explains why the problem is harder than it looks and where the specifications need review from people who will actually have to execute the migration.

The pressure comes from two directions that compound each other. XML Signature complexity has produced a sustained vulnerability class across SAML implementations, and most of the library stacks enterprises depend on are in various states of deferred maintenance. Post-quantum migration now adds a hard coordination deadline on top of that deferred debt. The organizations with the most SAML maintenance debt are the least equipped to execute a coordinated algorithm migration when the timeline becomes binding. That is not a coincidence. It is the same organizations that treated SAML as a procurement checkbox in the early 2010s who are now running aging library stacks with limited institutional knowledge of how to change them safely.

Post-quantum migration does not create new migration obligations for SAML estates. It converts deferred maintenance into a hard deadline.

OpenID Connect is not new. The OpenID Foundation ratified the core specification in February 2014. In October 2024, nine OpenID Connect specifications were published as ISO/IEC international standards. The protocol is mature, widely deployed, and built on the OAuth 2.0 stack with more than a decade of enterprise deployment behind it. And yet SAML is still the enterprise default for SSO.

Why SAML Still Wins

SAML remains dominant because the enterprise buying and operating model was built around it.

Many RFPs still ask for SAML by name. Compliance teams know how to evaluate it. SaaS vendors know that if they do not support SAML, they may lose enterprise deals before a security architect ever reads their OIDC documentation. Identity teams have years of runbooks for exchanging metadata, rotating certificates, mapping attributes, testing IdP-initiated and SP-initiated login, and recovering from lockouts. For browser-based workforce SSO, SAML is often boring in the best sense: it is well understood, broadly supported, and easy for enterprise administrators to reason about.

There is also a security intuition behind SAML that should not be dismissed. In a typical SAML deployment, the service provider pins trust to an IdP signing certificate or metadata document controlled by the customer. The customer can often bring their own PKI, rotate keys through a known administrative process, and reason about the blast radius of a compromised signing key in a way that feels concrete. OIDC, by contrast, is often perceived as more dynamic: the relying party discovers issuer metadata, follows a JWKS URL, and validates JWTs against keys published by the issuer. That model is mature and secure when implemented correctly, but a certificate uploaded into an admin console looks like a boundary. A URL that returns keys looks like a dependency.

SAML has not failed. The environment around it has. But enterprise familiarity is not the same thing as long-term safety. The question is no longer whether SAML can keep working. It is whether SAML should keep absorbing new enterprise identity requirements that its trust model was never designed to carry.

The Assertion Ceiling

SAML is a presentation layer for authentication. The assertion is the relationship.

When a user logs in, the IdP constructs an assertion encoding what it knows about that user at that moment: a subject identifier, authentication context, and whatever attributes the integration was configured to include. The service provider validates it, maps the claims into a local session, and moves on. That is the protocol boundary. There is no ongoing connection, no shared API surface, and no standardized way for the service provider to query the IdP after the assertion is consumed.

That boundary matters because the enterprise identity graph is larger and more dynamic than any assertion can carry. The organizational context that enterprise applications actually need (reporting structures, cost center assignments, entitlements across systems, device posture, group memberships that change as people move roles) cannot be practically embedded in a login-time assertion. Either the IdP preloads every attribute every application might ever need, or each application maintains its own copy through a separate provisioning channel, or it works with incomplete information about the user it just authenticated.

An application that needs to verify current entitlements before authorizing a sensitive operation cannot query the IdP through SAML. A service that wants to publish an access event back to the identity system has no standard SAML channel to do so. A policy engine that wants to evaluate real-time identity context at authorization time cannot call the IdP the way it would call any other API. Each of these capabilities requires a separate integration with a proprietary vendor API, a custom side channel, or nothing happens.

OIDC changes this because the service provider is an OAuth client. The IdP is an authorization server that can issue scoped, audience-bound, revocable access tokens the SP uses to call APIs on the user’s behalf when those APIs and scopes are part of the enterprise profile: richer profile queries, organizational data, entitlement lookups, event subscriptions.

The trust model is delegation-shaped, not assertion-shaped. SAML authenticates the user into the application. OIDC can also authorize the application to call identity APIs after login. Where SAML makes a one-time statement that the SP consumes and discards, OAuth tokens explicitly bind what the SP is allowed to do, against which APIs, for how long, and on whose behalf, with revocation as a first-class operation rather than an out-of-band hope. The authentication exchange can become an entry point, not a ceiling.

This is part of what IPSIE is defining: not just how OIDC handles SSO, but how the IdP’s API surface covers entitlements, lifecycle events, risk signal sharing, and the enterprise identity relationships that cannot live in an assertion. SAML provides no equivalent foundation.

The XML Problem

The issue is not that SAML is old. Old protocols can be excellent. The issue is the surface area created by XML and XML Signature.

SAML 2.0 is an OASIS standard for XML-encoded identity assertions, and its security depends heavily on correct XML canonicalization, reference resolution, ID handling, signature validation, and claim extraction. The relying party must not merely check that some signature is valid. It must ensure the signed element is the exact element whose claims are processed. That distinction sounds obvious until you look at the history of XML Signature wrapping and SAML validation bugs.

XML Signature signs specific nodes within a document, not the document as a whole. A wrapping attack inserts a second, unsigned copy of the assertion outside the signed scope. If the validator and the application disagree about which element to read, the signature check passes against the legitimate element while the application consumes claims from the attacker-controlled copy. The signed element is valid. The claims the application acts on are not from it.

The classic 2012 USENIX paper “On Breaking SAML: Be Whoever You Want to Be” analyzed 14 SAML frameworks and found critical XML Signature wrapping vulnerabilities in 11 of them. In 2018, Duo Labs disclosed SAML vulnerabilities affecting multiple implementations, including OneLogin libraries, OmniAuth-SAML, Shibboleth, and Duo Network Gateway. The mechanics differed across disclosures, but the security failure was the same: the implementation accepted one signed identity context while the application acted on another, allowing an attacker with a legitimate account in the same federation to authenticate as another user, including an administrator.

The pattern did not stop with the 2018 disclosures. In September 2024, a maximum-severity authentication bypass (CVE-2024-45409, CVSS 10.0) was disclosed in ruby-saml, a widely deployed library used by GitLab and other applications. The root cause was the same: the library failed to enforce that the elements it extracted claims from were covered by the signature it validated. An attacker with access to any SAML document legitimately signed by the IdP could forge a SAML response and authenticate as any user, including administrators, without that user’s credentials. Within weeks, working exploit code was published, turning a structural flaw into a point-and-click bypass. Additional critical ruby-saml disclosures followed in 2025, including CVE-2025-25291 and CVE-2025-25292, where parser differentials again allowed signature wrapping and authentication bypass. The twelve-year span from the original USENIX paper to the present has not resolved the structural problem. It has confirmed it.

This vulnerability record points to a structural supply-chain problem more serious than any individual disclosure. Most SaaS SAML implementations were built on open-source toolkits assembled during the early-to-mid 2010s, when enterprise SAML support was a procurement gate and implementation speed mattered more than long-term maintenance posture. The dependency graph runs from the SaaS product down through a SAML library, through an XML processing library, and into platform XML infrastructure. Each layer has its own release cadence, its own CVE history, and its own patch requirements.

The maintenance dynamic compounds the risk. SAML support is typically treated as a procurement feature: once the enterprise requirement is satisfied, the implementation joins the maintenance queue. In many organizations, the engineers who built the original SAML stack are no longer at the company. The XMLDSIG expertise required to safely evaluate a new vulnerability disclosure is not retained. A new CVE in a SAML library triggers a dependency update process, not a security design review, because the institutional context for a design review no longer exists.

This is what makes the XML problem structurally different from a standard software vulnerability. It is not one flaw in one implementation that can be patched. It is a property of XMLDSIG that creates a high-complexity validation problem for every implementation, reproduced across Java, Python, Ruby, PHP, and .NET, across different teams, in different decades, sustained indefinitely by a supply chain that treats SAML as a procurement checkbox rather than a security subsystem.

Post-Quantum Raises the Stakes

Post-quantum cryptography changes the SAML conversation because authentication signatures are squarely in the migration scope. The question is not just whether new algorithms can be added. It is whether the existing SAML estate can move to them before deferred maintenance becomes a compliance and availability problem.

NIST finalized its first post-quantum signature standards in August 2024: FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). NIST’s draft transition guidance, IR 8547, identifies RSA, ECDSA, and EdDSA as quantum-vulnerable signature standards and sketches a migration path away from them. Cloudflare has published a 2029 target for full post-quantum security across its infrastructure, including authentication. The direction is not speculative. The question for enterprise SAML estates is not whether authentication signatures need to move, but whether the SAML implementation substrate can execute that migration.

Federal agencies are already expected to inventory cryptographic dependencies. Enterprise identity platform procurement and migration cycles can run years for anything touching thousands of integrations. If algorithm deprecation requirements harden around 2030, the window to begin planning is already open. For organizations subject to federal compliance requirements like CMMC and FedRAMP, the pressure is more concrete: if those requirements arrive before the SAML implementation stack in production can support ML-DSA or SLH-DSA, the enterprise SSO infrastructure chosen for its auditability becomes a compliance liability.

Migrating SAML to post-quantum signatures means updating the signing algorithm in the IdP, distributing new public key material to every service provider’s trust configuration, updating the SAML library to implement the new algorithm, updating the XML Signature algorithm identifiers used in assertions, and ensuring every validation path in every relying party correctly processes the new key type and signature format. For large academic and research federations like InCommon in North America and eduGAIN across Europe, the coordination scope is far larger. InCommon alone connects more than 1,000 participating organizations through a centralized metadata authority, and eduGAIN federates thousands more across Europe. The centralized metadata model that makes SAML federation manageable in normal operations becomes an amplification factor for migration risk when a disruptive algorithm transition is required.

OIDC and OAuth sit on top of the JOSE family of standards (JWS, JWE, JWT, JWK, JWA), and the IANA JOSE algorithm registry is the extensibility point that lets new signature algorithms be added without protocol changes. A new signature algorithm needs a JWA identifier, a JWK representation, JWKS publication, and updated validation logic. The ecosystem plumbing for discovery, key rotation, JWKS caching, and metadata is already built to accommodate algorithm transitions.

That extensibility has now produced a concrete post-quantum standard. RFC 9964, published on the IETF Standards Track in May 2026, specifies ML-DSA (FIPS 204) for JOSE and COSE: algorithm identifiers, JWK key representations, signature encoding, and the ML-DSA-44, ML-DSA-65, and ML-DSA-87 parameter variants needed for interoperable implementation. An OIDC issuer can now publish ML-DSA keys at its JWKS endpoint against a published standard rather than a vendor extension, and any conformant relying party can validate them. No equivalent standards-track work exists for XMLDSIG. The XML Signature algorithm registry has no published post-quantum identifiers, no profile defining how ML-DSA or SLH-DSA keys appear in SAML metadata, and no agreed encoding for those signatures on the wire. Enterprise SAML estates needing post-quantum signatures will be waiting on standards work that has not started, while OIDC deployments are waiting on implementation of a standard that already exists.

A post-quantum XMLDSIG profile, whenever it arrives, would not escape the deeper problem. As noted above, XML Signature signs specific nodes rather than the document as a whole, and that node-versus-consumed-element gap is the wrapping class itself. JWS signs the entire token as a single unit, so that class of attack structurally cannot arise. Swapping in ML-DSA changes the signing algorithm; it does not change which bytes are protected. A post-quantum SAML would inherit the same validation surface that produced twelve years of wrapping disclosures, while JWS never had it.

The post-quantum migration for OIDC is not free. RFC 9964 is a target to build to, not a finished deployment. But there is a material difference between an ecosystem where the standard exists and implementations need to catch up, and one where the standards work itself has not yet started. The same SaaS organizations that have not kept their SAML library dependency current for routine CVE patches will face a more complex migration: new algorithm support requiring new library versions, new key management, new certificate infrastructure, and coordination with every customer integration. Unlike a routine CVE patch, there is no option to defer indefinitely. Organizations that deferred longest carry the most concentrated coordination risk when migration timelines become binding.

Why Migration Is Hard

Saying new SSO integrations should use OIDC is the easy part. Migrating the existing estate is not.

Most enterprise applications in production already have established SAML federations. Those integrations are tied to user identifiers, group mappings, role assignments, SCIM provisioning, app sessions, break-glass processes, help desk runbooks, audit expectations, and contractual support language. Changing the SSO protocol is not a refactor. It is an operational event with outage risk.

From the customer’s perspective, the upside often looks small. If the migration goes perfectly, users may see one extra redirect or no visible change at all. If it goes badly, users are locked out, the help desk floods, executives cannot access critical apps, and the identity team owns the incident.

This is why SAML persists even when everyone in the room agrees that OIDC is the modern direction. The migration cost is immediate and local. The security benefit is long-term and systemic. The person approving the migration carries the outage risk while the benefit accrues to a future operating model.

Vendors keep implementing SAML because customers require it. Customers keep requiring SAML because vendors support it and their existing estate runs on it. New vendors that would prefer to implement OIDC still worry that excluding SAML will shrink their enterprise TAM. If they expect to support SAML eventually, they implement it early and add yet another SAML stack to the world.

A single enterprise SAML integration may depend on a NameID format, custom attribute mappings, group-to-role rules, SCIM provisioning assumptions, certificate rotation procedures, IdP-initiated launch behavior, session timeout expectations, and help desk recovery paths. None of those show up in a simple protocol comparison chart. Every one can break during migration.

The missing ingredient is not a better argument for OIDC. It is a migration path that is explicit, standardized, and low-risk enough that the people approving migrations can trust it, and that vendors can build to without inventing a bespoke solution for every customer.

That is the gap the migration profile is trying to standardize: not a new login protocol, but a way to prove that an OIDC client is the successor to an existing SAML service provider relationship.

Two Things Would Help

A Secure Enterprise OIDC Profile

The first missing piece is a clearer definition of secure enterprise SSO for OIDC.

The OpenID Foundation’s IPSIE Working Group is working toward that: profiles for enterprise identity covering single sign-on, user lifecycle management (SCIM), entitlements, risk signal sharing (via the Shared Signals Framework and CAEP), logout, and token revocation, with a charter that explicitly prioritizes secure defaults. That work matters because “supports OIDC” is not a security claim. OIDC has its own failure modes: issuer mix-up, redirect URI mistakes, weak state or nonce handling, unsafe account linking, tenant-claim misuse, and JWKS caching errors.

OAuth’s recent evolution is the closest precedent. RFC 9700 (BCP 240) updates the OAuth 2.0 security baseline based on more than a decade of deployment experience, and OAuth 2.1 is consolidating those lessons into the core authorization framework by requiring PKCE for all clients, removing weaker grant types like the implicit grant and Resource Owner Password Credentials, and requiring exact redirect URI matching. The FAPI 2.0 Security Profile goes further, demonstrating that a hardened OIDC profile can be defined and conformance-tested at scale, originally for high-assurance financial APIs. IPSIE applies the same approach to enterprise SSO. Enterprise buyers need an equivalent baseline for OIDC SSO. Vendors need a target they can build to and demonstrate conformance against. Optionality is where interoperability and security both go to die.

A Real SAML-to-OIDC Migration Story

The second missing piece is a standardized migration path that preserves identity contract continuity.

It is not enough to tell customers to create a new OIDC application and cut over. Migration has to preserve the identity contract the application already depends on. That means mapping SAML issuers, NameIDs, attributes, groups, and tenant identifiers into OIDC issuer and claim semantics without breaking subject resolution. It means supporting staged rollout, dual configuration, telemetry, rollback, and test modes. At minimum, a credible migration story needs to cover:

• Preserve subject continuity across the protocol switch, accounting for both SAML NameID format variation (persistent, transient, email, X.509 SubjectName) and OIDC’s pairwise versus public sub semantics, so the application does not accidentally create a second account for the same user.
• Establish the OIDC trust anchors as successors to the existing SAML relationship, with defined bindings from SAML IdP EntityID to OAuth issuer and from SAML SP EntityID to OAuth client identifier, so the new trust relationship is provably the continuation of the existing one rather than a parallel federation.
• Map SAML AudienceRestriction (typically the SP EntityID URI) onto OIDC aud (typically a client_id) without weakening audience validation in either direction.
• Map SAML attributes, groups, and tenant identifiers into OIDC claims without changing application authorization semantics.
• Define the scope of the migration with respect to the OAuth token model: whether the profile covers ID-token-only authentication, or also access and refresh tokens with their independent lifetimes, scopes, and revocation semantics.
• Support parallel validation during rollout so administrators can test the new OIDC path before disabling SAML.
• Give the application a way to distinguish an intentional protocol migration from accidental or malicious account linking.

The industry does not yet have a standard answer to any of these requirements. Each vendor that has attempted SAML-to-OIDC migration has invented its own approach, with its own subject-mapping logic, its own account-linking semantics, and its own untested edge cases. That bespoke improvisation is what makes migration feel more dangerous than it should be, and it is why some migrations that appeared to succeed produced silent account-linking errors that only surfaced later.

Consider a user whose SAML identity was a persistent, opaque NameID, but whose new OIDC integration resolves identity from the email claim. The cutover does not throw an error. It silently creates a second account, while the user’s group memberships, entitlements, license assignment, and audit history stay attached to the original. The user logs in, sees an empty workspace, and files a ticket. Nobody connects it to the migration. The failure mode that costs the most is not the one that pages the on-call engineer at cutover. It is the one that surfaces months later as two accounts for one person in an access review, or as orphaned entitlements a compliance audit cannot explain.

The migration profile is built for exactly this. It uses RFC 8693 Token Exchange and SAML assertion introspection to bind new OAuth clients to existing SAML SP relationships through registered saml_sp_entity_id and saml_idp_entity_id metadata, so the trust anchor, audience, and subject derivation carry forward from the original federation rather than being reinvented per vendor. A three-way binding among the authenticated client, the registered SP EntityID, and the assertion audience is what lets applications verify a migration is intentional rather than an accidental, or malicious, account-linking event.

No SAML estate moves all at once, so the migration profile is now one of three interoperability profiles that let old trust and new trust run side by side. Each covers one direction of the transition, and together they describe a staged journey rather than a single switch:

The unit of migration is the integration, not the company. Each SP moves when it is ready, and nothing in front of it has to wait.

The phases overlap rather than gate each other, which is the point: old trust and new trust recognized simultaneously, with a defined handoff point rather than a hard cutover, the same parallel operation the SHA-1 transition relied on. The specifications are early. They need review from the identity providers, application vendors, and enterprise architects who know where the real edge cases are.

What to Do Now

Enterprise buyers should stop making SAML the default requirement for new SSO. Treat SAML as a legacy compatibility protocol, while new enterprise SSO requirements should require secure OIDC support with documented SAML-to-OIDC migration semantics. Concretely, replace language like:

The solution must support SAML 2.0 for enterprise SSO.

with:

The solution must support SAML 2.0 for enterprise SSO, or an enterprise OIDC profile with documented migration semantics that preserve subject continuity for accounts currently authenticating via SAML. Vendors must demonstrate how existing SAML integrations can be migrated to OIDC without requiring account re-linking or high-risk cutovers.

The more important question is not whether a vendor supports both protocols, but how they handle migration: does their OIDC implementation preserve subject continuity for accounts that currently authenticate via SAML, or does it require a high-risk cutover? That question, asked early in procurement, changes what vendors prioritize. Buyers should also inventory existing SAML integrations for the ones most likely to become blockers: custom NameID formats, fragile attribute mappings, manual certificate rotation, and undocumented group and role mappings are the integrations that make migration expensive.

Application vendors should stop treating SAML as a checkbox dependency. Prefer OIDC for new enterprise SSO, while treating existing SAML support as legacy-critical infrastructure that requires real maintenance. That means dependency tracking, XMLDSIG test coverage, signature-wrapping regression tests, and certificate-rotation hygiene. The test to apply: can you migrate a SAML customer to OIDC without creating a second account or disrupting their group and role assignments? If the answer is no, the OIDC implementation is not production-ready for enterprise migration.

Identity providers and standards groups should make migration conformance-testable. IPSIE can define the secure enterprise OIDC baseline. Migration profiles can define how existing SAML relationships move without account-linking ambiguity or high-risk cutovers. Conformance tests can turn those expectations into something verifiable rather than aspirational.

The organizations that start now will have chosen their timeline. The ones that wait will have it chosen for them, by the next signature-validation disclosure, a supply-chain failure in a SAML library they forgot they depended on, or a post-quantum deprecation deadline that arrives before their XMLDSIG stack is ready to move.

The destination is not exotic. It is enterprise SSO on a hardened OIDC profile, with post-quantum signatures published against a standard that already exists, reached by a migration path that carries existing SAML relationships forward without orphaning a single account. The technology to get there is arriving. The only open question is whether the planning starts before the deadline does.

Get Involved

SAML 2.0 and OpenID Connect Interoperability Profiles

The interoperability profiles are early-stage drafts, not finished standards. They cover three complementary directions: the Migration profile (SAML SP to OIDC), the Bridge profile (an OP serving un-migrated SAML SPs through an IdP facade), and the IdP-backed OP profile (an OP delegating authentication to an upstream SAML IdP). The goal is to get the problem definition and requirements in front of people who will actually have to execute this migration, and find out where the approach is wrong before it goes further.

If you work on enterprise identity, one of these questions is probably worth your time:

• Identity providers: Does this profile describe what your migration tooling already does? Where does it conflict with your implementation, and where are the gaps?
• SaaS application vendors: If you support both SAML and OIDC today, does this profile give you a workable path to migrate existing SAML customers without a high-risk cutover? What is missing?
• Enterprise architects: If you are planning or deferring a SAML-to-OIDC migration, does this profile address the identity contract requirements that make migration feel risky?
• Standards reviewers: The subject-mapping semantics and trust relationship model should be challenged. If the approach does not hold for your deployment scenario, that feedback is exactly what shapes whether this becomes a useful standard.

Feedback and discussion are open on GitHub.

IPSIE Working Group

The IPSIE Working Group at the OpenID Foundation is defining what secure enterprise OIDC actually means in practice: profiles for SSO, user lifecycle management, entitlements, risk signal sharing, logout, and token revocation. That work is only as good as the enterprise requirements it is built against.

If you are an enterprise buyer with real deployment constraints, an identity provider with implementation experience, or a SaaS vendor who has navigated the gap between “supports OIDC” and “secure for enterprise,” the working group needs your input. The specifications produced there will become the baseline that procurement language can require and vendors can build to. Getting the requirements right now is easier than correcting them after conformance tests exist.

Information on participating is available at openid.net/wg/ipsie.