SAML and SSO together: what identity teams need to know

At a glance

What this is: A practical explanation of how SAML and SSO fit together, with a clear distinction between protocol and access experience.

Why it matters: It matters because identity teams must govern authentication paths, session trust, and federation choices consistently across human users, NHI-adjacent services, and mixed enterprise environments.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read StrongDM's guide to how SAML and SSO work together

Context

SAML and SSO are often discussed as if they were interchangeable, but they solve different problems in the identity stack. SSO is the user experience of signing in once and reaching multiple resources, while SAML is one of the federation protocols that carries identity assertions between the identity provider and the service provider.

For IAM teams, the governance question is not just whether users can get in easily. It is whether authentication trust, session duration, certificate handling, and provisioning rules remain consistent across apps, databases, servers, and federated partners. That same discipline applies whenever identity is used as a control plane for access, not just for employees at a login screen.

Key questions

Q: How should security teams choose between SAML and OIDC for enterprise access?

A: Use SAML for browser-based enterprise federation where signed assertions and mature IdP trust are the priority. Use OIDC when modern web, mobile, or API-first access needs lighter-weight token handling. The decision should follow application architecture, assurance needs, and how well each protocol supports logging, session control, and identity lifecycle governance.

Q: What breaks when SSO is treated as a substitute for access governance?

A: Access becomes easier to authenticate but harder to govern. If teams rely on SSO alone, they can overlook provisioning, de-provisioning, certificate hygiene, and session duration settings. That leaves entitlements alive longer than intended and creates a false sense of control because login centralisation is mistaken for lifecycle assurance.

Q: How do identity teams know whether SAML federation is being trusted too broadly?

A: Look for service providers that accept assertions without strong request validation, weak certificate handling, or unusually long sessions. Broad trust also shows up when access persists after role changes or offboarding. If the federation layer is healthy, authentication events should be visible, attributable, and revocable without manual workarounds.

Q: Who is responsible when SAML-based access goes wrong?

A: The service provider and identity provider both carry responsibility, but the accountability model must be explicit before federation goes live. Security, IAM, and application owners should agree on who manages trust metadata, who revokes access, and who investigates assertion failures. Without that clarity, federation problems become cross-team blind spots.

Technical breakdown

How SAML assertions support SSO federation

SAML uses signed assertions to move identity facts from an identity provider to a service provider after authentication. The service provider trusts the assertion because it is cryptographically signed and scoped with timestamps, audience restrictions, and certificate validation. In practice, this lets an organisation centralise authentication while allowing different applications to rely on the same identity decision. SSO is the user experience layered on top of that exchange, not the exchange itself.

Practical implication: Validate assertion signing, certificate lifetimes, and audience restrictions before expanding federation to more applications.

SP-initiated and IdP-initiated SAML flows

SP-initiated SAML starts when an application sends the user to the identity provider for authentication, then checks the returned response against a known request. IdP-initiated SAML begins in the identity provider portal and sends the user straight to the app with a fresh assertion. The first pattern gives the service provider more context for response validation, while the second reduces friction but weakens request-response binding. Both are legitimate, but they create different trust surfaces.

Practical implication: Use SP-initiated flows for higher assurance paths and reserve IdP-initiated flows for portals where the risk trade-off is understood.

SAML, OIDC, and Kerberos in the same access stack

Enterprises rarely run one protocol in isolation. SAML often fits browser-based enterprise applications, OpenID Connect fits modern web and API-driven access, and Kerberos remains common inside domain-bound environments. The control challenge is not choosing a favourite protocol. It is preserving consistent identity assurance, session handling, logging, and provisioning across multiple trust models without creating hidden exceptions in the access architecture.

Practical implication: Map each protocol to a specific use case and keep policy, logging, and provisioning requirements aligned across them.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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 is an identity transport layer, not an access governance model. The protocol moves signed identity claims between trusted parties, but it does not decide entitlement design, lifecycle offboarding, or privileged scope. That distinction matters because many organisations treat federation success as if it were governance success. It is not. Practitioners should separate authentication plumbing from access governance if they want reliable control over who or what can act in the environment.

Single sign-on concentrates control, which is useful only if the surrounding governance is mature. SSO reduces password fatigue and centralises authentication, but it also means the identity provider becomes a high-value decision point for many applications at once. If provisioning, de-provisioning, session duration, and certificate management are weak, the centralised model magnifies failure instead of reducing it. Identity teams should treat SSO as a control multiplier, not a control substitute.

Protocol choice now has lifecycle consequences across human and non-human access paths. SAML, OIDC, and Kerberos are often selected for technical fit, but the real issue is how each one supports review, revocation, and auditability across the identity estate. Service accounts, application identities, and delegated access paths may not use SAML directly, but they are still affected by the same governance discipline. The practitioner takeaway is to evaluate federation as part of end-to-end identity lifecycle design, not as a standalone integration task.

Federation failures often begin where identity trust is assumed rather than verified. The guide’s emphasis on encryption, certificate validation, request checking, and audit logging reflects a deeper governance reality: trust without continuous validation becomes an operational assumption. That is true for human SSO, and it becomes even more consequential when the same identity fabric is extended into workload and service access. Teams should examine where trust is inherited automatically and whether that inheritance is still defensible.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• That is why teams should pair federation design with Ultimate Guide to NHIs , Key Challenges and Risks when they evaluate trust boundaries and credential exposure.

What this signals

Identity federation is becoming a control-plane issue, not just a login convenience issue. As more applications and services depend on central identity decisions, the quality of certificate handling, session policy, and provisioning discipline becomes a programme-level risk. Teams that still treat SAML as a point integration will miss the broader governance effect. The practical shift is to review federation with the same rigour used for privileged access and offboarding.

Federation sprawl creates hidden lifecycle debt. The strongest warning sign is not whether users can sign in once, but whether revoked users, retired apps, and stale trust relationships are still active in the background. With Ultimate Guide to NHIs showing that NHIs outnumber human identities by 25x to 50x in modern enterprises, the same discipline that secures human SSO must extend to service and workload identity paths.

SAML, OIDC, and Kerberos are converging into one governance problem. Different protocols will continue to coexist, but the audit question is increasingly whether each one produces evidence that can be reviewed, revoked, and correlated across the identity estate. That is where identity programmes should prepare for more cross-domain policy work, not more isolated protocol tuning.

For practitioners

• Separate protocol selection from governance design Document which applications use SAML, OIDC, Kerberos, or native credentials, then define the assurance and lifecycle controls that apply to each path. Keep federation choices from becoming a shortcut around entitlement review.
• Harden assertion trust checks Enforce certificate validation, signed assertions, audience restrictions, and short session durations for every SAML relying party. Re-test these controls whenever metadata, certificates, or trust relationships change.
• Align SSO with provisioning and de-provisioning Tie IdP access to joiner-mover-leaver workflows so access does not outlive the user relationship. Make de-provisioning visible in audit logs and recertification evidence.
• Log federation events as identity evidence Capture token issuance, assertion validation failures, and session creation events in a format that security and IAM teams can review together. That evidence is what lets you distinguish healthy federation from silent over-trust.

Key takeaways

• SAML and SSO are related but not interchangeable, and confusing them weakens governance as organisations scale federation.
• Centralised authentication only improves security when provisioning, revocation, certificates, and sessions are controlled with equal discipline.
• Identity teams should treat federation design as part of lifecycle governance across applications, services, and access paths.

Key terms

• Single Sign-On: Single sign-on is an authentication pattern that lets a user access multiple applications after one successful login. It reduces repeated prompts and password fatigue, but it also concentrates trust in the identity provider and session controls that sit behind the experience.
• SAML Assertion: A SAML assertion is a signed XML statement carrying identity, attribute, or authorisation data from an identity provider to a service provider. Its security depends on certificate trust, time limits, audience restrictions, and strict validation before the service provider accepts it.
• Identity Provider: An identity provider is the system that authenticates a subject and issues the identity claims other applications trust. In enterprise federation, it becomes a governance point for login assurance, attribute accuracy, session policy, and revocation when access must end.
• Federated Authentication: Federated authentication is the practice of letting one trusted identity system vouch for a user or system across multiple services. It simplifies access, but it also creates shared trust dependencies that must be controlled through policy, logging, and lifecycle management.

Deepen your knowledge

SAML and SSO governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning federation controls with broader identity lifecycle management, it is worth exploring.

This post draws on content published by StrongDM: SAML vs. SSO: What's the Difference and How They Work Together. Read the original.