I recall attending identity related talks 15 years ago speaking to the notion of “SAML is dead” and OIDC will take over as the de facto identity provider protocol. It was great to learn about concepts like UMA (User-Managed Access), PKCE (Proof Key for Code Exchange), and all of the delegated authorization goodness coming out of OAuth 2.0 and subsequent RFCs. Yet here we are in 2025, and SAML remains very much alive.
There’s hardly a week that goes by without encountering an organization needing a SAML IdP specifically for their customer-facing solutions. Initially, this requirement can seem puzzling—especially since many of these same organizations already have a SAML IdP in place for workforce scenarios, alongside an OIDC-based solution for customer identity management. Sometimes, the same identity platform covers both scenarios, making the need for an additional SAML solution even more perplexing. The real issue emerges clearly upon closer inspection: these organizations typically rely on white-labeled third-party SaaS solutions, and many of these solutions exclusively support SAML for authentication. Adding further confusion, most of these SaaS providers emerged well after predictions of SAML’s decline, raising the obvious question: why haven’t they adopted OIDC yet?
Not every organization faces this issue, particularly those whose entire ecosystem (including 3rd party) is either exclusively SAML or fully modernized to support OIDC. However, I encounter this mixed-protocol scenario more often than expected. My very next question after hearing this is almost always- why isn’t this third party SaaS solution supporting OIDC, in addition to SAML? The reality is despite all of the promises (some realized and some not) OIDC has provided, SAML remains stubbornly prevalent, particularly within the B2B SaaS ecosystem. I see there being six main reasons this is the case:
- Mature Enterprise Adoption
- Customer Demand and Competitive Pressure
- Resource Constraints and Complexity
- Legacy Infrastructure
- Perceived Security and Trust
- Slow-moving Enterprise IT
Let’s dive into these six reasons.
Mature enterprise adoption
SAML had a significant head start over OIDC and with enterprise adoption at scale, SAML became deeply embedded within corporate IT and identity infrastructures- starting as early as 2002. Because SAML gained widespread adoption early on, many large organizations standardized their authentication processes, security policies, and governance frameworks around SAML. For SaaS providers targeting enterprise customers, offering SAML ensures compatibility with these entrenched systems and helped with accelerating adoption.
Customer Demand and Competitive Pressure
From a purely commercial perspective, SaaS providers prioritize features based on direct customer demand and competition. Many large enterprise buyers explicitly demand SAML support as a baseline requirement, thus SaaS providers have less incentive to adopt additional standards like OIDC. As long as their primary market continues to emphasize SAML compatibility, providers often choose to delay or deprioritize OIDC adoption.
Resource Constraints and Complexity
Supporting multiple identity protocols increases complexity, cost, and maintenance overhead for SaaS providers. Each identity standard—such as SAML and OIDC—has unique implementation details, protocol flows, security considerations, and integration patterns. Providers, especially those with limited resources or legacy platforms, often focus their development efforts on the most universally accepted standard, which in the B2B market continues to be SAML.
Legacy Infrastructure
Many SaaS platforms originally built when SAML was the dominant standard face significant technical debt and limitations in easily adopting newer identity protocols like OIDC. Upgrading or rebuilding existing authentication subsystems to support modern standards often requires considerable investment and architectural changes, which can be prohibitively expensive or complex for providers with extensive legacy code.
Perceived Security and Trust
SAML, due to its age and widespread enterprise use, is perceived as robust, secure, and trustworthy by enterprises. Security, compliance, and audit teams within enterprise customers often feel more comfortable with familiar, battle-tested technologies. This leads them to prefer or mandate SAML-based integrations, influencing SaaS providers to continue prioritizing SAML compatibility to satisfy these security-driven customer requirements.
Slow-moving Enterprise IT
Enterprise IT systems evolve slowly, particularly in highly regulated industries (financial services, healthcare, government). These organizations often cannot quickly shift to newer technologies due to compliance audits, risk assessments, and regulatory constraints. Consequently, SaaS providers targeting these markets remain anchored in SAML, aligning with their customers’ slower-paced technology adoption cycles.
Ultimately, the persistence of SAML-only SaaS providers arises from a combination of customer demand, legacy system constraints, resource prioritization, and market-driven pressures. These factors create a significant barrier to rapid protocol modernization in many SaaS environments. Here in March of 2025, more than ever, organizations are looking to discover cost optimizations in any way possible. This may lead to organizations of all sizes, across all industries and verticals, to migrate from monolithic and/or prohibitively priced identity solutions to high valued, feature-rich, and low cost cloud based solutions. And this may lead to edge use cases where an organization may require a SAML response to a downstream service provider.
So, how do we bridge this gap between OIDC-based identity providers and SAML-only SaaS service providers? As solution architects, we always explore practical, scalable, and secure options. One approach I’ll dive into next is building a serverless SAML gateway that seamlessly handles the exchange between modern OIDC IdPs and legacy SAML-based SaaS service providers. In part two of this series, “the Ugly” (coming soon), I’ll share a detailed reference architecture, sequence diagrams, and some practical code snippets, giving you everything you need to tackle this integration challenge head-on.