OIDC vs SAML: How a two-decade-old protocol still dominates identity federation
Discover why the decades-old SAML protocol remains indispensable for enterprise SSO and federation, how it compares to modern OpenID Connect, and what the future of identity federation holds.
In the identity and access management world, two protocols have long been at the forefront: SAML (Security Assertion Markup Language) and OpenID Connect (OIDC).
OIDC is newer, lighter, and seemingly more developer-friendly.
Given these advantages, why does SAML still dominate enterprise authentication?
The answer is more nuanced than just saying “it’s too much work to migrate.” This is a story about history, architecture, and the complexities of federation.
The rise of SAML
At the dawn of federated authentication in the early 2000s, enterprises faced a major challenge: enabling employees to log into multiple applications securely without juggling passwords.
Password fatigue and fragmented access control were significant pain points. SAML emerged as the groundbreaking solution, designed specifically to allow identity providers like Active Directory to issue signed XML assertions that service providers could trust.
This standardized and interoperable approach—based on well-defined OASIS specifications that ensure any compliant identity provider can work with any compliant service provider— unlocked a wave of early SSO implementations and rapidly became the backbone of enterprise authentication.
Major IdPs like ADFS, Ping, Okta, and Shibboleth embraced it, and thousands of SaaS applications followed suit, eager to integrate with enterprise customers.
As more vendors and organizations adopted SAML, a powerful network effect took hold, further solidifying its role as the dominant federation protocol.
The migration challenge
Enterprises have invested years of effort in configuring SAML-based SSO. HR systems, provisioning pipelines, and access policies rely on SAML assertions packed with rich attributes describing user roles and entitlements.
Moving away from this would not only be costly but also risky, potentially disrupting critical authentication flows.
Changing protocols isn’t just a technical task—it requires revalidating compliance, retraining teams, and coordinating with countless external partners. This massive web of trust keeps SAML firmly embedded in enterprise identity ecosystems.
OIDC vs. SAML: Architectural differences
While migration costs are significant, there’s a deeper reason why SAML persists: OIDC doesn’t yet replicate everything SAML offers.
SAML’s architecture differs significantly from OIDC’s in several key areas. Let’s dig into it.
Assertions vs JWTs
Even though OpenID Connect is the modern standard, SAML continues to thrive in enterprises because its architecture carries richer, standardized semantics that many legacy applications rely on:
- SAML Assertions: Digitally signed XML documents that carry rich, hierarchical identity information that’s well-suited for complex enterprise needs like role-based access control and license management. For example, a SAML assertion might include a full organizational structure with nested department and permission attributes used by legacy ERP systems to determine access rights. SAML attributes are typed and hierarchical by default. Statements like AuthnStatement (authentication context), AttributeStatement (rich identity attributes), and AuthzDecisionStatement (authorization decision) have distinct, standardized roles. This allows consuming enterprise applications to parse not just data but meaning (e.g., “this is a decision statement permitting read access to resource X”).
- OIDC JSON Web Tokens (JWTs): Lighter and simpler to parse but less suited to complex, nested attribute information. They work well for modern consumer and mobile applications but lack SAML’s expressive detail. While you can pack arrays or even nested JSON to mimic hierarchy, JWTs are schemaless. There’s no standardized separation between authentication, attributes, or authorization decisions. Each relying party must interpret custom claims individually, leading to less interoperability in complex, policy-driven enterprise environments. Additionally, in OIDC, tokens typically only provide identity claims and scopes, leaving authorization decisions to separate API calls or policy engines. The JWT itself doesn’t natively carry or enforce granular authorization statements like SAML does.
Multi-application federation vs app-centric tokens
SAML was architected in the early 2000s with cross-domain, multi-application federation as a core design goal. In a classic hub-and-spoke model, a single Identity Provider (IdP) can establish persistent, trust-based relationships with hundreds of Service Providers (SPs). Once a user authenticates with the IdP, that authentication and rich attribute set can be securely reused across numerous applications without re-prompting for login.
Enterprise ecosystems, like large universities or multinational corporations, often connect dozens or hundreds of applications (HR systems, ERP, CRM, intranets) through a centralized IdP. SAML’s protocol defines metadata exchange, entity identifiers, and trust negotiation mechanisms that make onboarding new SPs predictable and scalable. For example, when adding a new HR platform, administrators simply exchange signed metadata XML and instantly extend SSO to the entire workforce.
OpenID Connect was designed primarily for modern web and API-based authentication. While an OIDC provider can serve multiple applications, its architecture is inherently app-specific: tokens are typically issued for a single “client” (application) and audience. Setting up SSO across many applications requires manual, per-app client registration and configuration, often leading to duplicated settings and fragmented policies.
OIDC lacks a standardized metadata exchange mechanism as rich as SAML’s federation model. Trust onboarding is less automated, and there’s no built-in equivalent of SAML’s hub-and-spoke federation that scales to hundreds of apps with minimal configuration. This is why complex enterprise environments with legacy apps and intricate access models still rely heavily on SAML for true federation across domains and vendors.
Compliance and auditing
SAML was built with enterprise security and regulatory compliance in mind:
- Assertions carry detailed authentication context (such as multi-factor methods used, session timestamps, and authentication class references), along with extensive metadata about the Identity Provider (IdP) and Service Providers (SPs).
- Every assertion is digitally signed and can be encrypted, ensuring integrity and confidentiality end-to-end.
- These capabilities produce comprehensive audit trails, enabling organizations to prove exactly who logged in, how they authenticated, and what access decisions were made.
- This traceability aligns naturally with stringent regulations like HIPAA, SOC 2, FINRA, and government-grade compliance frameworks, which often require strong non-repudiation and detailed security event logging.
OpenID Connect favors performance and simplicity over verbosity. Its JWT tokens carry essential identity claims but lack the same depth of contextual and operational metadata that SAML assertions standardize. While OIDC supports token signing and optional encryption, it does not inherently include detailed audit-related statements (e.g., multi-factor auth context or per-resource authorization decisions).
In heavily regulated industries where auditors expect cryptographically verifiable, context-rich assertions, organizations often rely on SAML to meet compliance mandates. OIDC can achieve similar outcomes, but it requires additional custom logging and policy tooling, increasing implementation complexity.
Federation ecosystem and trust models
SAML has been deployed for over two decades, creating mature, globally recognized trust frameworks. Industries like education, research, and government have built large-scale federations (e.g., InCommon, eduGAIN, US Federal Identity Ecosystem) where hundreds or thousands of organizations interoperate seamlessly.
These federations rely on standardized metadata exchange, established trust anchors, and widely interoperable tooling, enabling universities, agencies, and vendors to quickly form cross-organizational SSO agreements. SAML’s long history and proven governance models have made it the default choice for many multi-party federation scenarios where interoperability is non-negotiable.
OpenID Connect has rapidly gained adoption for modern applications and APIs, but its multi-party federation ecosystem is still maturing. While initiatives like OpenID Connect Federation 1.0 aim to bring similar metadata exchange and trust models to OIDC, adoption is early compared to SAML.
Current OIDC implementations typically operate as point-to-point trust relationships, requiring manual client registration and configuration between each Identity Provider (IdP) and Relying Party (RP). As a result, OIDC has not yet matched the scale and automated trust interoperability that decades of SAML deployments have delivered in academic and governmental federations.
These architectural differences explain why enterprises rely on SAML for complex SSO and federation, even as OIDC adoption grows.
Has SAML declined?
While OIDC adoption is growing rapidly for modern, consumer-facing applications, SAML usage remains steady in enterprise contexts. Many SaaS platforms support both protocols, indicating coexistence rather than replacement. Federation networks continue to rely heavily on SAML.
Can OIDC replace SAML?
While OpenID Connect is rapidly becoming the default for modern apps and APIs, it has not yet reached feature parity with SAML in the complex world of enterprise identity. For OIDC to fully replace SAML, it would need to mature in several key areas:
- Standardize support for multi-statement tokens, enabling clear separation of authentication context, identity attributes, and explicit authorization decisions.
- Define interoperable ways to carry hierarchical attributes (departments → teams → roles) without relying on custom claims.
- Introduce a hub-and-spoke trust model similar to SAML’s federation capabilities, allowing an IdP to securely onboard and manage hundreds of applications with minimal per-app configuration.
- Automate metadata exchange and trust negotiation to scale multi-party deployments.
- Mature the OpenID Connect Federation 1.0 standard and achieve broad adoption across vendors.
- Establish global trust frameworks (similar to InCommon and eduGAIN) with standardized onboarding, governance, and interoperability.
- Add built-in support for detailed authentication context, including MFA methods and session security levels.
- Provide standardized, cryptographically verifiable audit trails matching or exceeding SAML’s assurances for HIPAA, SOC 2, and other regulated environments.
- Offer seamless bridging or compatibility layers for older applications that natively understand SAML assertions but not JWT claims.
- Develop standardized tooling to migrate complex SAML-based role and license models to OIDC without major rewrites.
- Demonstrate decade-scale, multi-party production reliability in the kinds of massive federations where SAML has already proven itself (government, education, multinational corporations).
Until these gaps are fully addressed and widely adopted, organizations will continue to rely on hybrid environments, using SAML for legacy, compliance-heavy applications and OIDC for modern, consumer-facing ones.
The future of federation
The future isn’t about choosing between SAML and OIDC; it’s about coexistence. The identity landscape is evolving rapidly, but federation itself isn’t going away. As organizations embrace multi-cloud strategies, distributed workforces, and hybrid application stacks, the need for trust-based, cross-domain identity federation is stronger than ever.
- Hybrid protocol coexistence: For the foreseeable future, SAML and OIDC will continue to coexist, each serving its sweet spot: SAML anchoring compliance-heavy, legacy environments and OIDC powering modern, API-first applications.
- Convergence and innovation: Standards bodies are working to bridge protocol gaps, such as OpenID Connect Federation 1.0, aiming to bring SAML-like multi-party trust ecosystems to OIDC. Over time, innovations may narrow functional differences, but replacing SAML entirely will be a decade-long journey.
- Enterprise demand for simplicity: Enterprises increasingly seek unified solutions that abstract protocol complexity, allowing developers to integrate SSO without mastering SAML or OIDC’s nuances. Platforms like WorkOS will play a crucial role in bridging these protocols, allowing developers to integrate both without wrestling with their complexities.
How WorkOS enables future-proof federation
WorkOS provides a modern SSO platform that bridges this protocol divide. Whether an organization’s Identity Provider speaks SAML 2.0 or OpenID Connect, WorkOS wraps the complexity of these legacy and modern protocols into a standard OAuth 2.0 interface for your application.
- Connect to any IdP (Okta, Azure AD, Google Workspace, Ping Identity, custom SAML, and more).
- Handle multi-app federation automatically, supporting both hub-and-spoke SAML setups and individual OIDC clients.
- Deliver enterprise-grade compliance and auditing without manually implementing SAML or OIDC’s intricate flows.
- Future-proof your app’s authentication, allowing you to support both protocols seamlessly as the ecosystem evolves.
With WorkOS, you don’t have to bet on which protocol “wins.” Instead, you can integrate once and support every enterprise identity scenario—past, present, and future.