OIDC vs SAML: why enterprise federation still runs on SAML

At a glance

What this is: This article explains why enterprise federation still runs on SAML even as OIDC grows, focusing on richer assertions, multi-application trust, and audit-friendly identity context.

Why it matters: IAM teams need to understand where protocol choice affects federation scale, compliance evidence, and legacy application compatibility across human identity programmes.

Context

OIDC vs SAML is not just a protocol comparison. It is a governance question about how an identity programme carries trust, attributes, and audit context across many applications without breaking existing access flows.

SAML remains deeply embedded in enterprise SSO because it was designed for cross-domain federation, while OIDC is better suited to modern app and API patterns. For IAM, IGA, and PAM teams, the practical issue is not protocol preference alone but whether the federation model still matches the organisation's application estate.

The article frames a familiar enterprise trade-off: richer, standardised assertions and metadata exchange versus lighter, app-centric tokens. That trade-off becomes most visible where compliance, legacy systems, and large-scale IdP-to-SP trust relationships all have to coexist.

Key questions

Q: How should security teams choose between SAML and OIDC?

A: Choose SAML when you need mature enterprise federation for browser-based applications and central assertion handling. Choose OIDC when you need a lighter identity layer for APIs, native apps, mobile apps, or modern service workflows. The right decision depends on the application class, trust model, and how much claim data downstream systems require.

Q: Why does SAML still work better for some regulated identity environments?

A: SAML is better aligned to regulated environments when identity events need to be cryptographically verifiable and richly contextual. Its assertions can carry authentication details, identity attributes, and trust metadata in a standard form that supports audit evidence. OIDC can meet similar needs, but usually with extra logging and policy tooling.

Q: What breaks when organisations try to replace SAML too quickly?

A: What usually breaks is not login alone. Teams lose standardized attribute handling, established federation workflows, and in some cases the audit trail that regulated applications expect. The result is fragmented identity behaviour, manual compensating controls, and avoidable application rework.

Q: What is the difference between hub-and-spoke federation and app-centric trust?

A: Hub-and-spoke federation lets one identity provider manage trust across many service providers through shared metadata and repeatable onboarding. App-centric trust configures each client relationship separately, which is simpler for one app but harder to scale across a broad enterprise estate. The difference is scale of governance, not just protocol syntax.

Technical breakdown

SAML assertions vs OIDC JWTs

SAML assertions are signed XML documents that separate authentication context, attributes, and sometimes explicit authorisation statements into standardised elements. That structure gives relying applications a consistent way to interpret who authenticated, what attributes were asserted, and what the IdP intended to convey. OIDC JWTs are lighter and easier to parse, but they usually collapse identity into claims and scopes that each application must interpret. In complex enterprise environments, that increases variability, because the same token can be handled differently by different services. The architectural difference is not just payload format. It is whether the federation layer carries meaning in a reusable, standards-based way or pushes interpretation into each consuming application.

Practical implication: Treat SAML and OIDC as different federation semantics, not interchangeable token wrappers.

Hub-and-spoke federation vs app-centric client registration

SAML was built around a hub-and-spoke trust model in which one identity provider can maintain relationships with many service providers through metadata exchange and predictable federation onboarding. That model supports large enterprise estates where identity trust must be extended across dozens or hundreds of applications without repeating the same setup from scratch. OIDC can support multiple applications, but each client relationship is typically configured separately, which makes federation more app-specific and less automatically scalable. The difference matters when enterprise identity is trying to standardise trust across many partners, business units, or legacy services. OIDC can be sufficient for a single application chain, but SAML still fits broad federation topologies better.

Practical implication: Match protocol choice to the trust topology you actually operate, not to the newest standard.

Why auditability keeps SAML relevant

SAML includes standardised authentication context and signed assertions that can preserve richer evidence about how a user authenticated and what trust relationship carried the transaction. That makes it easier to build consistent audit trails in regulated environments where the identity event itself becomes part of the control evidence. OIDC can also be secured, but teams often need additional logging and policy tooling to reach comparable context depth. The article's deeper point is that auditability is a protocol design issue, not a reporting afterthought. Where auditors expect cryptographically verifiable identity events, SAML still aligns more naturally with enterprise control requirements.

Practical implication: Use protocol selection as part of your evidence model, not just your login experience.

NHI Mgmt Group analysis

Protocol choice is now a federation governance decision, not a developer convenience decision. WorkOS correctly shows that the SAML versus OIDC question persists because enterprise identity is still shaped by trust topology, legacy application requirements, and audit expectations. That means IAM teams should evaluate protocol support as part of programme architecture, not as a front-end integration preference. The real constraint is whether the identity model can still express trust at enterprise scale.

SAML remains the stronger fit where identity attributes must travel with meaning. Rich assertions are not just about more data. They let enterprise systems preserve the distinction between authentication context, attributes, and explicit access semantics in ways that many policy-heavy environments still depend on. That is why the protocol continues to matter in ERP, HR, and regulated access paths where attribute fidelity is part of the control design.

OIDC does not fail because it is weaker; it fails where enterprise federation demands more structure than app-centric claims naturally provide. The gap is not token modernity but federated semantics. If the identity programme expects per-app interpretation of claims to replace standardised federation meaning, then the operating model shifts from shared trust to custom handling. Practitioners should see that as a governance choice with long-term complexity, not a syntax preference.

Legacy compatibility is not technical debt in isolation, it is an identity control dependency. Organisations often describe SAML retention as migration drag, but the article shows that many access flows, provisioning assumptions, and compliance artefacts are already built around it. Removing SAML prematurely can destabilise the trust fabric that makes enterprise SSO auditable and repeatable. The implication is to govern coexistence deliberately rather than treat protocol replacement as inevitable.

Federation standardisation is the named concept that explains the market split. SAML has mature federation standardisation: standard metadata, predictable trust onboarding, and interoperable relationships across many parties. OIDC is still closing that gap through newer federation work, but the market already reflects two operating models. Practitioners should design for coexistence because the protocol that best serves a single app is often not the protocol that best serves an enterprise federation programme.

What this signals

Hybrid federation is the operating reality, not a temporary compromise. Enterprise IAM programmes are likely to keep both SAML and OIDC in play because their application estates are mixed by design. The governance challenge is to assign each protocol where its trust model fits best and to avoid forcing one standard to do both legacy federation and modern app authentication.

Protocol modernisation should be measured against control continuity. If a migration strips out authentication context, attribute fidelity, or verifiable audit trails, the programme may become simpler to code but harder to govern. That is why protocol roadmaps should be reviewed alongside federation policy, application onboarding, and evidence requirements.

For practitioners

• Map applications by federation complexity Separate legacy, compliance-heavy, and multi-party federation dependencies from modern app-only integrations before choosing a protocol path.
• Preserve SAML where rich assertions matter Keep SAML in place for workloads that rely on hierarchical attributes, authentication context, or explicit federation trust relationships.
• Standardise OIDC for modern app patterns Use OIDC where the application estate is API-first, client-specific, and does not depend on SAML-style metadata exchange.
• Document audit evidence expectations Define which identity events must be cryptographically verifiable, then align the protocol and logging model to that requirement.

Key takeaways

• SAML persists because enterprise federation still depends on rich assertions, scalable trust relationships, and audit-friendly identity context.
• OIDC is well suited to modern apps, but it does not automatically replace the semantics that many legacy and regulated environments still require.
• The safest path is deliberate coexistence, with each protocol aligned to the trust model and control evidence its applications actually need.

Key terms

• Federation entity: A federation entity is an organisation or technical participant that publishes metadata describing its keys, endpoints, and capabilities. It is the unit of participation inside the federation, and it can be an identity provider, relying party, wallet provider, or AI agent acting on behalf of a system.
• SAML Assertion: A SAML assertion is the signed XML message that carries authentication and access claims from an identity provider to a service provider. It tells the receiving system who was authenticated, what attributes were shared, and whether access should be granted, so the trust in the session depends on the quality of that assertion.
• OpenID Connect Token: An OpenID Connect token is a machine-readable credential used to convey identity claims in an OAuth 2.0 based flow. It is typically lighter than a SAML assertion and fits modern applications well, but it demands strong issuer, audience, and expiration checks to avoid token misuse.
• Hub-and-Spoke Model: A hub-and-spoke model is an architecture where a central hub coordinates communication, control, or data flow between multiple connected spokes. In identity and security, the hub often enforces policy, aggregates telemetry, or brokers access, while spokes represent systems, applications, or environments that depend on the hub for consistent governance and routing.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.