SAML and SSO together: what identity teams need to know

At a glance

What this is: This guide explains how SAML and SSO relate, showing that SSO is the user experience and SAML is one protocol that can implement it through federated authentication.

Why it matters: IAM teams need this distinction to avoid treating protocol choice, identity-provider trust, and session governance as separate problems when they are tightly linked in modern access design.

Context

SAML and SSO are often discussed as if they were interchangeable, but they solve different parts of the access problem. SSO is the access pattern that lets a user sign in once and reach multiple applications, while SAML is one of the standards that carries identity information between the identity provider and service provider.

That distinction matters for identity governance because it changes where authentication is verified, where trust is established, and how sessions are managed across apps, databases, and servers. Once the IdP becomes the control point, teams have to think about federation, session duration, certificate handling, and de-provisioning as part of one access model rather than isolated controls.

The article is a protocol and governance explainer, not a breach report. Its practical value is in helping teams choose when SAML fits, when OIDC is a better fit, and how SSO changes the shape of control in enterprise IAM.

Key questions

Q: How should teams decide whether SAML is the right protocol for an application?

A: Choose SAML when the application needs browser-based federation, enterprise IdP trust, and signed assertions across multiple domains. Use it when centralized authentication is the main requirement and the app can safely rely on the IdP for identity decisions. If the access path is mobile-first, API-heavy, or JSON-oriented, another protocol may fit better.

Q: Why does SSO make identity governance easier and harder at the same time?

A: SSO makes governance easier because it centralises authentication and creates a clearer view of access activity. It makes it harder because any error in trust, role design, or deprovisioning can affect many systems at once. That is why teams must govern the identity provider as part of the control plane, not as a convenience layer.

Q: What breaks when SAML assertions are not tightly validated?

A: If assertions are accepted without full signature, audience, recipient, and time-window checks, an application can log in the wrong subject or trust a replayed token. That creates identity confusion at the session layer and can turn a valid federation event into unauthorised access. Validation must be strict because the SP is deferring trust to the IdP.

Q: When should organisations pair SSO with MFA and session controls?

A: They should do it whenever one login can unlock multiple applications, especially where the IdP becomes the central control point. MFA reduces the impact of credential theft, while session controls limit how long a successful login remains usable. Together they prevent convenience from turning into broad, persistent access.

Technical breakdown

How SAML assertions enable federated SSO

SAML works by moving signed identity assertions from the identity provider to the service provider after a user requests access. The assertion can include authentication status, attributes, and authorization context, which lets the service provider trust the IdP rather than re-authenticating the user. That federated model depends on certificates, message binding, audience restrictions, and time limits so the assertion cannot be replayed or redirected outside its intended scope. In practice, SAML is not the login experience itself; it is the trust mechanism underneath that experience.

Practical implication: treat assertion signing, certificate validation, and response audience checks as first-order governance controls, not implementation details.

Why IdP-initiated and SP-initiated flows are not equivalent

SP-initiated SAML starts with the application and includes a request that can be validated on the way back from the IdP. IdP-initiated SAML starts at the portal and sends the assertion directly to the service provider, which simplifies user flow but reduces some request-response validation. That distinction matters because the authentication path changes the amount of state the application can verify before accepting the assertion. The choice affects exposure to replay risk, portal trust, and how much assurance the service provider has about the original access request.

Practical implication: decide whether each application needs SP-initiated validation or can safely accept IdP-initiated access based on its risk profile.

Where SSO governance shifts once the IdP becomes the control point

SSO centralises access decisions, which reduces password fatigue but also concentrates governance in the IdP, session policy, and provisioning lifecycle. Once one identity system can unlock many applications, controls like MFA, session timeouts, automatic de-provisioning, and audit logging become the main boundaries around abuse. This is why SSO design is not just an authentication question. It is an access governance model that determines how consistently organisations can enforce trust across heterogeneous apps, services, and environments.

Practical implication: align IdP policy, session controls, and lifecycle offboarding so SSO does not become a single point of governance drift.

NHI Mgmt Group analysis

SAML and SSO are different control layers, and confusion between them weakens governance. SSO describes the user experience of authenticating once and reaching multiple applications. SAML is one of the mechanisms that makes that possible by carrying signed identity data between trust domains. Teams that collapse the two into one concept tend to misplace controls, especially around where verification happens and where session authority lives.

The real governance shift in SAML-backed SSO is the concentration of trust in the IdP. When one identity provider becomes the gatekeeper for many services, the weakest session and provisioning decision inherits the broadest blast radius. That makes certificate handling, assertion validation, MFA policy, and de-provisioning central to the access model rather than supporting tasks. The practitioner implication is that IdP governance is now application governance.

SAML remains useful where federation and browser-based enterprise access are the problem, but it is not the default answer for every access path. The article’s comparison with OIDC and Kerberos reflects a broader architectural point: protocol choice should follow the environment, not habit. Web apps, internal network services, and API-heavy systems do not all need the same trust pattern. Practitioners should match protocol to control requirement rather than forcing one federation model across all use cases.

SAML-backed SSO creates an identity trust boundary that must be managed like infrastructure, not like a convenience feature. The user sees a seamless login, but the organisation inherits certificate lifecycle, session policy, provisioning rules, and logging obligations behind it. That makes SSO a governance architecture with operational consequences across IAM, PAM, and application access. The right question is not whether SSO is simpler, but whether the control plane is mature enough to carry the trust load.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

SAML-backed SSO should be treated as a trust architecture, not a convenience layer. The control problem moves from repeated passwords to federation design, session policy, and the reliability of the IdP as the central decision point. For practitioners, that means the governance question is no longer whether users can log in once, but whether one login now governs too much.

Protocol choice matters because different access paths create different control requirements. SAML fits browser-based enterprise federation, while OIDC and Kerberos address different application and network patterns. Teams that standardise too aggressively around one protocol often create friction in the places where the control model matters most.

IdP concentration creates a single governance boundary that needs continuous review. If session duration, certificate handling, provisioning, and de-provisioning are owned separately, the organisation gets the benefits of SSO without the discipline needed to contain its blast radius.

For practitioners

• Define where SSO trust is established Map which application types should trust the IdP, which should require additional validation, and where SAML is not the right protocol for the access pattern.
• Harden assertion and certificate handling Validate SAML responses, enforce strict certificate checks, and treat assertion signing keys as high-value trust material with explicit ownership.
• Align session policy to application sensitivity Set session duration, reauthentication, and MFA requirements by risk level so a single SSO session does not overextend access across unrelated systems.
• Automate provisioning and de-provisioning Tie SSO access to joiner-mover-leaver processes so federated login rights are removed when role changes or offboarding events occur.
• Choose protocol by control requirement Use SAML for browser-based enterprise federation, OIDC where JSON-based and API-oriented access is a better fit, and Kerberos for internal network authentication.

Key takeaways

• SAML and SSO are related but not interchangeable, and confusing them hides where trust and session control actually live.
• The main governance shift is centralisation in the IdP, which raises the importance of assertion validation, certificate handling, MFA, and offboarding.
• Teams should choose protocols by control requirement, not habit, and align SSO policy to the sensitivity of each application.

Key terms

• Single Sign On: Single Sign On is a login method that lets a user access multiple applications with one authenticated session. Technically, an identity provider issues a trusted authentication assertion or token after the user signs in, and connected services accept that proof instead of requiring separate passwords for each application.
• Security Assertion Markup Language: A federated authentication protocol that lets an identity provider issue assertions to a service provider. It is commonly used for single sign-on in web and cloud environments, but it shifts trust into the identity provider and the assertion exchange, which makes governance and availability essential.
• 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.

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.