OIDC vs SAML: why enterprise federation still runs on SAML

At a glance

What this is: This is a protocol comparison showing why SAML still anchors enterprise federation while OIDC grows in modern apps and APIs.

Why it matters: It matters because IAM teams rarely get to replace federation in one move, and the protocol split affects SSO design, auditing, lifecycle integration, and application onboarding across human and machine-access programmes.

👉 Read WorkOS's analysis of OIDC vs SAML in enterprise federation

Context

OIDC and SAML solve the same business problem, but they do it with different federation assumptions. SAML was built for rich, cross-domain enterprise SSO, while OIDC was designed for lighter web and API authentication, which is why many organisations still run both in parallel.

For identity teams, the real question is not which protocol is newer. It is which protocol matches the application estate, trust model, and audit requirements already embedded in the identity programme. That matters across human SSO, delegated access, and any non-human workload that inherits enterprise federation patterns.

Key questions

Q: How should IAM teams decide between SAML and OIDC for enterprise apps?

A: Choose SAML when applications need rich attributes, mature federation, or detailed audit evidence. Choose OIDC when the use case is simpler, API-oriented, and the application can handle authorization separately. Most enterprises need both, so the real decision is where each protocol fits in the control model, not which one is more modern.

Q: Why do many enterprises keep SAML even after adopting OIDC?

A: They keep SAML because migration is not only technical. It also affects trust relationships, compliance evidence, legacy application behaviour, and onboarding processes across many service providers. When those dependencies are already built around SAML assertions, replacing them can create more risk than value.

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 protocol migration and identity governance?

A: Protocol migration changes how assertions or tokens move between systems, but identity governance determines who owns the trust relationship, what evidence must be retained, and how onboarding and offboarding are controlled. A good migration plan must include governance ownership, not just technical compatibility.

Technical breakdown

SAML assertions vs OIDC JWTs in enterprise federation

SAML assertions are signed XML documents that separate authentication context, identity attributes, and authorization decisions into distinct, standardised statements. That gives downstream applications richer semantics for role handling, license checks, and audit reconstruction. OIDC ID tokens and JWTs are lighter and easier for developers to consume, but claims are typically app-specific and less structured. In practice, that makes OIDC better for simpler web and API use cases, while SAML remains stronger where the relying party needs detailed identity meaning, not just proof of authentication.

Practical implication: map your application population by attribute complexity before deciding which protocol to standardise on.

Multi-application federation vs per-app client registration

SAML’s federation model was designed around hub-and-spoke trust, where one identity provider can onboard many service providers through standard metadata exchange and established trust anchors. That reduces friction when dozens or hundreds of applications need to trust the same identity source. OIDC usually works as a point-to-point client relationship, which is cleaner for individual apps but creates more per-application setup and policy duplication at scale. The architectural difference is one reason SAML still fits large enterprise estates with many legacy and compliance-bound applications.

Practical implication: if your programme supports many internal and third-party apps, treat federation onboarding as a scaling problem, not just a protocol choice.

Compliance, auditing, and federation trust models

SAML commonly carries richer authentication context, signed assertions, and optional encryption, which helps organisations reconstruct who authenticated, how they authenticated, and what was asserted at the time. That traceability is useful where auditors expect non-repudiation and clear evidence trails. OIDC can support secure authentication too, but detailed audit evidence usually requires extra logging and policy layers outside the token itself. The result is that SAML often remains the easier fit for regulated environments, especially where federation partners already rely on mature trust frameworks.

Practical implication: validate audit evidence requirements before migrating regulated applications off SAML.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SAML persists because enterprise federation is still a trust problem, not just a token problem. The article shows that SAML’s value comes from rich assertions, standardized metadata exchange, and mature multi-party trust relationships. Those properties matter when an enterprise must onboard many apps, preserve compliance evidence, and keep legacy systems operating. Practitioners should treat federation as an ecosystem decision, not a front-end authentication preference.

OIDC is not a drop-in replacement for complex federation estates. The article makes clear that OIDC works well for lighter application flows, but it does not yet match SAML’s native support for hierarchical attributes, standardized statement separation, or hub-and-spoke federation at scale. That means protocol rationalisation can increase operational burden if teams assume modern syntax automatically means better governance. The practitioner takeaway is to match protocol choice to the access model, not the trend line.

Protocol coexistence is the enterprise default because migration cost is also governance cost. Revalidating compliance, retraining teams, and rebuilding trust relationships are not side effects of protocol change. They are the programme work that determines whether identity migration succeeds or becomes disruptive. IAM leaders should expect hybrid federation for the foreseeable future and design policy, logging, and onboarding processes accordingly.

Federation maturity is becoming a control-plane issue across human and workload identity alike. The same architectural question appears whenever an identity source must be trusted by many relying parties with different policy needs. That is why federation design now intersects with lifecycle governance, application onboarding, and enterprise trust architecture. Teams should align protocol strategy with the broader identity control plane, not only the SSO implementation.

Named concept: federation semantics debt. SAML carries a mature set of trust semantics that many enterprise applications already depend on, while OIDC often requires custom interpretation to recreate equivalent behaviour. That debt accumulates when organisations want modern developer ergonomics without giving up hierarchical attributes, audit detail, or broad trust interoperability. The practitioner conclusion is that protocol simplification is never free when downstream governance depends on semantics.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means federation decisions often sit on top of incomplete identity inventory.
• That visibility gap is why the NHI Lifecycle Management Guide matters when protocol choices expand beyond human SSO into third-party and workload access.

What this signals

Federation architecture is becoming a lifecycle issue, not just a login issue. The moment an application estate spans SAML, OIDC, and third-party access, teams need ownership for onboarding, offboarding, and evidence retention across all three. That is where protocol choice starts to affect the whole identity programme, not just the authentication layer.

With 97% of NHIs carrying excessive privileges, according to Ultimate Guide to NHIs, federation design should be assessed alongside entitlement scope and trust boundaries. A protocol that is easy to connect but hard to govern can still widen the blast radius.

Federation semantics debt: as organisations modernise authentication, they often recreate SAML-like behaviour through custom claims, local policy engines, and compensating controls. That creates hidden complexity, especially when the same identity source must serve humans, service accounts, and external partners across mixed estates.

For practitioners

• Inventory protocol dependence by application class Map which applications require hierarchical attributes, explicit authentication context, or multi-party federation. Separate those from apps that only need simple token claims so protocol decisions reflect actual control needs.
• Preserve SAML where audit evidence is part of the control requirement Keep SAML for regulated or legacy applications that rely on signed assertions, rich context, and non-repudiation. Reassess only when the replacement path can produce equivalent audit trails.
• Standardise onboarding for hybrid federation Create a repeatable process for adding SAML and OIDC applications, including metadata exchange, client registration, and policy ownership. This reduces duplication when both protocols must coexist.
• Separate authentication from authorization decisions Document where identity proof ends and resource authorization begins, especially for OIDC deployments that depend on downstream policy engines. This prevents teams from assuming the token itself carries more control than it does.

Key takeaways

• Enterprises keep SAML because federation needs rich semantics, not just a modern token format.
• OIDC simplifies developer workflows, but it does not automatically replace the governance and audit properties many organisations still need.
• The right identity strategy is hybrid by design, with protocol choice driven by application risk, trust scale, and evidence requirements.

Key terms

• Federation semantics: The meaning carried by identity assertions as they move between an identity provider and relying parties. In enterprise IAM, semantics include authentication context, attributes, and sometimes authorization intent, which allows downstream systems to make decisions without re-interpreting the token from scratch.
• SAML assertion: A signed XML statement that conveys identity and authentication information from an identity provider to a service provider. It is commonly used in enterprise federation because it can express detailed attributes, authentication context, and trust metadata in a standardized format.
• OIDC token: A lightweight identity token used in OpenID Connect to communicate authentication results and claims to an application. It is easier to parse than SAML but typically carries less standardized structure, so enterprises often rely on extra policy and logging around it.
• Hub-and-spoke federation: A trust model where one identity provider serves many applications through a central trust relationship. It simplifies onboarding and policy consistency for large application estates, especially when many service providers need to trust the same source of identity.

Deepen your knowledge

OIDC vs SAML federation strategy is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is supporting mixed protocol estates, the course helps you anchor those decisions in governance rather than tool preference.

This post draws on content published by WorkOS: OIDC vs SAML: how a two-decade-old protocol still dominates identity federation. Read the original.