TL;DR: SAML remains a core enterprise SSO protocol because it lets identity providers authenticate users once and pass signed assertions to service providers, reducing password storage and login friction, according to WorkOS. Its limits are increasingly visible in mobile, API-first, and customer-facing environments, where OIDC and OAuth often fit better.
At a glance
What this is: SAML is an enterprise authentication standard that enables single sign-on by letting an identity provider assert a user’s identity to trusted applications.
Why it matters: It matters because IAM teams still need to decide where SAML belongs in the architecture, where OIDC is a better fit, and how to keep SSO secure without overextending a protocol beyond its strengths.
Context
SAML remains a core identity protocol because enterprise applications still need a trusted way to centralise authentication without forcing users to manage separate credentials for every service. In practice, the question is not whether SAML exists, but where it is still the right fit in an IAM architecture that also has to support mobile, APIs, and customer-facing access.
The governance gap is that many teams treat SSO as a single design choice when it is really a protocol selection problem. SAML, OAuth, and OpenID Connect solve different parts of the access model, and mixing them without clear boundaries creates avoidable complexity in authentication flows, attribute handling, and application onboarding.
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 do SAML implementations become harder to govern in modern app stacks?
A: SAML works best in a browser-based enterprise federation model, but modern stacks often require mobile-friendly login, delegated API access, and self-serve customer onboarding. Those requirements introduce more certificate coordination, attribute mapping, and compatibility work. Governance gets harder because the protocol is being stretched beyond the environment it was designed for.
Q: What are the biggest mistakes teams make when they mix SAML, OAuth, and OIDC?
A: The biggest mistake is treating them as interchangeable login methods. SAML handles authentication, OAuth handles delegated authorisation, and OIDC adds authentication to OAuth for modern login flows. When teams blur those roles, they create brittle integrations, unclear ownership, and access models that are difficult to audit or explain.
Q: What should IAM teams review before expanding enterprise SSO with SAML?
A: Review how the IdP signs assertions, how the service provider validates them, and whether attribute mappings are stable enough for production use. Also confirm that the application really needs SAML rather than a more modern protocol, especially if the service includes mobile, API, or customer-facing access paths.
Technical breakdown
How SAML assertions move identity across trusted apps
SAML is built around an identity provider and a service provider. The IdP authenticates the user, then issues a signed SAML assertion that the service provider trusts and consumes to create a session. The protocol is browser-centric and XML-based, which suits federated enterprise login but makes the flow more rigid than modern token-based approaches. Because the service provider does not need to collect or store the user’s password, the protocol also reduces local credential exposure and shifts authentication controls to the IdP.
Practical implication: Standardise IdP trust, signature validation, and attribute mapping before onboarding more applications into SAML.
Why SAML and OAuth solve different identity problems
SAML is an authentication protocol. It answers who the user is and is commonly used for enterprise SSO. OAuth is an authorisation framework. It answers what an app can do on behalf of a user, especially when API access is involved. OpenID Connect sits on top of OAuth 2.0 to add authentication for modern login flows. The confusion happens because modern apps often combine these layers, but the control boundary still matters: SAML carries identity assertions, OAuth carries delegated access, and OIDC handles login for web, mobile, and consumer experiences.
Practical implication: Separate login, delegation, and API access decisions so the wrong protocol is not forced into the wrong control plane.
Why SAML becomes brittle in mobile and API-first architectures
SAML was designed for browser-based enterprise federation, not for native mobile apps or API-heavy workflows. Its XML payloads, certificate coordination, and attribute dependencies introduce implementation overhead that grows as application estates diversify. In environments with customer-facing apps or self-serve onboarding, that overhead becomes a governance issue as much as a technical one, because the organisation has to maintain compatibility, assurance, and troubleshooting across many IdPs and service providers. That is why modern identity stacks often keep SAML for enterprise SSO while using OIDC or OAuth where the architecture demands more flexible token handling.
Practical implication: Reserve SAML for browser federation and use modern protocols where the application model depends on mobile or API interaction.
NHI Mgmt Group analysis
SAML is still an enterprise control, not a universal identity layer. The article shows that SAML continues to solve a very specific problem: federated authentication between trusted identity providers and enterprise service providers. That makes it durable in B2B SSO, but it does not make it the right default for every application pattern. Practitioners should treat protocol choice as an architectural decision, not a migration checkbox.
Protocol boundary drift is the real architectural risk. When teams blur SAML authentication, OAuth delegated access, and OIDC login flows, they create systems that are hard to reason about and harder to govern. The issue is not SAML itself but the assumption that one protocol family can cover every identity use case. Identity architecture stays cleaner when authentication, authorisation, and federation are deliberately separated.
Enterprise SSO design still starts with the identity provider, not the application. SAML works because the service provider delegates authentication trust to the IdP and validates a signed assertion instead of collecting credentials locally. That model is still sound for centralised workforce access, especially where password storage would increase risk. The practitioner takeaway is to anchor trust at the IdP and let application requirements drive protocol selection.
Federation scope creep: SAML’s governance value depends on keeping it inside the browser-based enterprise login domain it was built for. The moment organisations stretch it into mobile, API, or customer journeys that need different token behaviour, the architecture becomes harder to secure and explain. Practitioners should preserve SAML where it fits and stop treating it as the universal answer to SSO.
SAML and OIDC are not competing labels for the same control. They reflect different identity designs with different trust mechanics. SAML is assertion-centric and enterprise-facing, while OIDC is token-centric and better aligned to modern application delivery. IAM teams should use that difference to reduce protocol sprawl rather than layering protocols until the access stack becomes opaque.
What this signals
Federation scope should follow the application model. SAML remains a strong choice for enterprise browser SSO, but the architectural boundary matters more than protocol familiarity. When identity teams keep SAML inside the use cases it was built for, they reduce protocol sprawl and make trust relationships easier to explain and govern.
Modern IAM programmes need a cleaner separation between authentication, authorisation, and federation. That separation becomes especially important as organisations add mobile apps, APIs, and customer identities to a stack that may still rely on SAML for workforce access.
For practitioners
- Define protocol boundaries by application pattern Use SAML for browser-based enterprise SSO, then route mobile, API, and customer-facing login journeys to the protocol that matches their runtime and token needs.
- Inventory where SAML assertions are still the right trust mechanism Map each connected application to the authentication model it actually needs, and retire SAML only where the application model depends on modern token flows or delegated API access.
- Separate authentication from authorisation design Document which flows need identity assertions, which need delegated API access, and which need login sessions, so teams do not force one protocol to do all three jobs.
- Harden IdP and assertion handling Validate signature checks, audience restrictions, certificate rotation, and attribute mapping for every SAML trust relationship before expanding enterprise SSO coverage.
Key takeaways
- SAML still matters because it centralises enterprise authentication through a trusted identity provider and reduces password handling at the service layer.
- The practical limitation is architectural, not conceptual: browser federation is where SAML fits best, while mobile and API-heavy environments usually need different protocol choices.
- IAM teams should map protocol choice to application pattern and keep authentication, delegated access, and federation decisions separate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C — Federation | The article centres on federated authentication between identity providers and service providers. |
| Recommendation — Apply federation guidance to keep SAML trust relationships explicit and bounded. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on access assertions and who is allowed into connected apps. |
| Recommendation — Align SSO design with access-authorisation governance across all relying applications. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | The article contrasts SAML with OAuth and OIDC, which affects how apps consume identity and access APIs. |
| Recommendation — Use API trust boundaries to keep delegated access separate from enterprise authentication. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SAML-based SSO is a workforce authentication pattern governed by organisational user identity controls. |
| Recommendation — Use organisational identity controls to validate SSO sessions before granting application access. | ||
Key terms
- 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.
- Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
- Service Provider: A service provider is the application or service that consumes an identity assertion and decides whether to allow access. It is responsible for validating the assertion, enforcing local authorisation, and limiting session scope, which means federation still requires strong downstream control.
- Federated Authentication: Federated authentication lets one organisation or platform accept a login performed by another trusted identity system. The application no longer verifies the user directly. Instead, it consumes signed claims or assertions, which makes trust relationships, certificates, and attribute mapping part of the security boundary.
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.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org