Notifications
Clear all
Topic starter
08/06/2026 4:42 pm
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.
NHIMG editorial — based on content published by WorkOS: SAML explained simply, what it is and how it works
Questions worth separating out
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.
Q: Why do SAML integrations still need strong governance if they centralise login?
A: Because centralised login does not eliminate lifecycle risk.
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.
Practitioner guidance
- 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.
- 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.
- Separate authentication from authorisation decisions Document which systems authenticate users, which systems issue assertions, and which systems control API permissions.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SAML SSO setup guidance for app builders who need implementation detail beyond the protocol overview
- Practical examples of IdP and service provider configuration, including the trust exchange that happens during login
- Comparison guidance for when to choose SAML, OIDC, or OAuth based on application architecture and access pattern
- Developer-focused onboarding options such as self-serve enterprise SSO setup for customer-facing applications
👉 Read WorkOS's SAML explainer and setup guidance for enterprise SSO →
SAML, SSO, and the IAM trade-offs teams still face?
Explore further
08/06/2026 6:28 pm
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.
A few things that frame the scale:
- 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.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
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.
👉 Read our full editorial: SAML still shapes enterprise SSO and IAM architecture choices
