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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “SAML explained simply: What is it and how it works”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: SAML still matters because it centralises enterprise authentication through a trusted identity provider and reduces password handling at the service layer.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A question worth separating out:
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.
👉 Read our full editorial: SAML still shapes enterprise SSO and IAM architecture choices