SAML still shapes enterprise SSO and IAM architecture choices

At a glance

What this is: This is a plain-English explanation of SAML and the key finding is that it still underpins enterprise SSO even as modern app architectures expose its limits.

Why it matters: It matters because IAM teams must decide where SAML remains the right federation pattern and where human, workload, and application identity controls need different protocols.

👉 Read WorkOS's SAML explainer and setup guidance for enterprise SSO

Context

SAML is an authentication protocol that lets an identity provider verify a user once and pass that trust to multiple service providers. In practice, that means one corporate login can unlock many applications without each app storing a password.

For IAM programmes, the real question is not whether SAML works. It is where SAML-based federation still fits enterprise SSO, where OIDC is a better match for modern login flows, and where OAuth should stay limited to delegated authorisation rather than identity assertion.

Key questions

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

A: Choose SAML for enterprise browser SSO, OAuth for delegated API access, and OIDC for modern authentication flows that need user login plus lightweight protocol support. The right choice depends on what the application is doing, who the identity subject is, and which trust boundary must be controlled. If those three are unclear, the integration will be hard to govern later.

Q: Why do SAML integrations still need strong governance if they centralise login?

A: Because centralised login does not eliminate lifecycle risk. Teams still need to manage certificates, metadata, attribute releases, and offboarding across every connected service. If those controls drift, SAML becomes a fragile trust dependency rather than a stable SSO pattern.

Q: How do I know if SAML is the wrong fit for an application?

A: SAML is usually the wrong fit when the application is mobile-first, API-driven, or needs delegated permissions rather than enterprise SSO. If the app needs token-based access, fine-grained scopes, or non-browser workflows, OIDC or OAuth is usually the better governance match.

Q: What should IAM teams do before enabling a new SAML connection?

A: Confirm the identity provider owner, attribute mappings, certificate rotation process, and offboarding path before the first login test. That gives the SSO connection a governance model, not just a technical handshake, and reduces the chance of long-lived access problems later.

Technical breakdown

How SAML assertions and trust validation work

SAML uses an identity provider and a service provider connected through browser redirects and a signed XML assertion. The identity provider authenticates the user, then issues a SAML response that the service provider validates using certificates, endpoint configuration, and attribute mapping. The service provider does not need to store the user’s password, which shifts trust to the federation boundary. That also means the security model depends on accurate metadata, certificate hygiene, and correct claim handling. If any of those pieces are misconfigured, login failures or trust breaks follow.

Practical implication: treat SAML as a federation control plane and review certificates, metadata, and attribute mappings as part of access governance.

SAML vs OAuth and OIDC in enterprise identity

SAML is built for authentication, OAuth is built for authorisation, and OIDC adds authentication on top of OAuth 2.0. That difference matters because the protocols solve different problems. SAML is usually the right fit for enterprise web SSO between a corporate identity provider and SaaS apps. OAuth should govern delegated API access, not user login by itself. OIDC is often a better fit for modern applications, especially mobile and consumer-facing services, because it uses lighter-weight JSON-based flows and supports contemporary login patterns.

Practical implication: map each application to the protocol it actually needs, rather than forcing SAML into API and mobile use cases.

Why SAML still persists in enterprise SSO architectures

SAML persists because it aligns well with federated enterprise identity, centralized authentication, and application ecosystems that are already wired for browser-based SSO. It is especially common where organisations want to reduce password storage in downstream apps and centralise MFA at the identity provider. The trade-off is operational complexity. SAML setup demands precise coordination across signing certificates, endpoints, and user attributes, which makes it durable but not lightweight. That is why many environments keep SAML for employee SSO while using OIDC elsewhere.

Practical implication: preserve SAML where it already solves a stable enterprise problem, but do not extend it into use cases it was not designed to cover.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 remains an authentication control, not an identity strategy. The article describes a protocol that centralises login trust, but the governance problem sits above the protocol layer. SAML can reduce password sprawl and improve control consistency, yet it does not by itself solve provisioning, lifecycle, or privilege governance. Practitioners should read it as one federation mechanism inside a broader IAM architecture, not as the architecture itself.

SAML’s value is strongest where the actor is a human user with browser-based access. That framing matters because the protocol was designed for enterprise SSO across web applications, not for API-first or workload identity patterns. When teams try to force it into every access path, they create mismatch between protocol design and actual access behaviour. The implication is that protocol selection must follow identity subject and access pattern, not enterprise habit.

Protocol confusion is a governance failure, not a terminology issue. The article’s comparison of SAML, OAuth, and OIDC reflects a real operational risk: teams routinely blend authentication and authorisation decisions. When those boundaries blur, access reviews, application onboarding, and integration design all become less reliable. Practitioners should separate who proves identity, who grants delegated access, and who authorises resource use.

SAML setup complexity shows why federation controls need lifecycle discipline. Certificate rotation, endpoint mapping, and attribute governance are not edge details. They are the operational conditions that keep enterprise SSO trustworthy over time. A federation programme that lacks certificate ownership and assertion review will eventually drift into brittle integrations and avoidable outages. Practitioners should govern SAML as a lifecycle-managed control, not a one-time integration.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Forward pivot: The identity boundary is now wider than SAML federation alone, which is why practitioners should pair protocol decisions with the Ultimate Guide to NHIs , What are Non-Human Identities and NIST Cybersecurity Framework 2.0.

What this signals

Federation decisions are becoming governance decisions. Teams that still treat SAML as a login project will miss the broader issue: authentication is only one layer of identity control. As application estates diversify, protocol choice now signals how mature an organisation is about subject type, trust boundary, and lifecycle ownership.

Attribute release is the hidden control point in many SSO designs. SAML works best when claims are tightly scoped and periodically reviewed, because the assertion becomes the security boundary once the user authenticates. That is where identity governance starts to overlap with application risk, especially when one assertion unlocks many downstream entitlements.

Protocol choice is also where NHI and human IAM diverge. Human SSO often maps cleanly to SAML, but machine and workload identities need different controls, especially when third-party OAuth relationships are involved. The practical signal is simple: if your SSO model cannot explain who or what the identity subject is, the programme is already under-specified.

For practitioners

• Map applications to the correct protocol class Use SAML for browser-based enterprise SSO, OIDC for modern login flows, and OAuth for delegated API access. Do not use protocol familiarity as the deciding factor; use identity subject, application architecture, and the trust boundary you actually need to govern.
• Review federation metadata and signing certificates Assign ownership for certificate rotation, endpoint validation, and attribute mapping so SAML assertions continue to validate cleanly across all connected apps. Include these checks in change management, because federation failures often look like application outages before they look like identity issues.
• Separate authentication from authorisation decisions Document which systems authenticate users, which systems issue assertions, and which systems control API permissions. This prevents teams from treating OAuth as login by itself and helps avoid building access policy on the wrong protocol.
• Treat SSO onboarding as lifecycle governance When a new SaaS app joins the estate, define how identity attributes, offboarding, and access review will work before the first SAML connection goes live. That keeps federation from becoming an isolated technical setup with no governance wrapper.

Key takeaways

• SAML is still a foundational enterprise SSO protocol, but it is only one part of IAM governance.
• The main decision is not whether SAML works, but whether the application and identity subject actually fit a browser-based federation model.
• Teams should govern SAML connections with the same discipline they apply to lifecycle, certificates, and attribute release policies.

Key terms

• SAML assertion: A SAML assertion is a signed message from an identity provider that states a user has authenticated and may be trusted by a service provider. It carries identity claims and trust data, so the consuming application can grant access without storing the user’s password.
• Identity provider: An identity provider is the system that authenticates a user and issues the trust statement used by downstream applications. In SAML environments, it becomes the central authority for login assurance, claim release, and many of the operational controls that govern access.
• Service provider: A service provider is the application that trusts the identity provider’s SAML assertion and uses it to create the user session. It depends on correct metadata, certificate validation, and attribute mapping, which makes it part of the federation control surface rather than a passive endpoint.
• Federated identity: Federated identity is a model where one trusted identity system vouches for a user across multiple applications. It reduces duplicated credentials and centralises authentication, but it also concentrates risk at the trust boundary, so lifecycle and configuration controls matter as much as the login flow.

Deepen your knowledge

SAML, SSO, and federation boundaries are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is deciding where browser-based identity fits alongside modern workload and application access, it is worth exploring.

This post draws on content published by WorkOS: SAML explained simply, what it is and how it works. Read the original.