SSO vs SAML Protocol Distinctions

A security team says "we use SAML" when what they mean is "we use SSO, and SAML happens to be how we deliver it." That slip sounds harmless, but it's a category error, and it leads teams to make decisions at the wrong level of the stack. SSO is an authentication capability: you log in once, and that one login reaches many systems. SAML is a protocol, one technical method for making that outcome happen. Duo's explainer puts the split this way: SSO is "a method or user experience for accessing multiple systems with one set of credentials," while SAML is "a protocol used to exchange authentication and authorization data. NinjaOne draws the same line: "SSO is an authentication model, while SAML is a protocol that can enable SSO." Deciding you want SSO is deciding you want centralized authentication. Deciding on SAML is deciding how to build it, the same way a team might decide it wants real-time communication and then separately decide whether WebSocket is the way to deliver that.

What SSO is and what it requires from a protocol

SSO exists to fix problems that appear the moment a company grows past a handful of applications: employees drowning in separate passwords, IT teams who can't fully revoke access when someone leaves because credentials are scattered across a dozen systems, and security policies that get enforced in one app but not another. SSO solves this by centralizing authentication under one authority, so a single login event covers every connected system. Duo identifies the core requirements that any SSO setup needs to meet: centralized authentication through a single authority, consistent security policy enforcement, reduced credential exposure, and streamlined administrative control.

None of those requirements name a specific protocol, and that's the point. NinjaOne lists a wide field of protocols that can deliver SSO: SAML, OAuth, OpenID Connect, Kerberos, LDAP, Federated Identity Management, Shibboleth, WS-Federation, and Social Sign-In. SAML is one entry on that list, not the definition of the list. Whatever protocol a company picks has to handle four jobs at minimum: establishing trust between an identity provider and the service providers it connects to, passing secure assertions or tokens between them, managing sessions once a user is authenticated, and giving administrators a clean way to revoke access or log someone out everywhere at once.

That reframes the question an organization should actually be asking. Which protocol fits depends on the applications in use, the identity providers already in place, and the compliance rules the business has to follow. Duo gives a cross-domain example: a multinational company wants employees moving between Slack, Salesforce, and Microsoft Teams without logging in again at each stop. That outcome is what SSO promises. Which protocol produces it is a separate decision, made later.

Just as SSO centralizes authentication to enforce consistent security policy across multiple applications, organizations managing AI agent access to business data face a parallel governance challenge: deciding which systems an agent can touch and enforcing that decision consistently across the company. MCPManager applies the same principle to AI data access, centralizing control over which AI agents can reach which business and consumer data, narrowing the exposure surface the same way SSO narrows credential exposure.

How SAML delivers SSO in practice

SAML is a standards-based protocol built on XML that delivers SSO through a specific mechanism: a trusted identity provider issues a signed document called an assertion, and service providers accept that document as proof the user already logged in somewhere trustworthy. Duo defines SAML as "an open standard for exchanging authentication and authorization data between parties, typically an identity provider (IdP) and a service provider (SP)," using XML-based tokens to carry that data.

Three parties sit inside this model. The user is the person trying to get into an application. The identity provider is where that person's credentials actually live and where the real authentication check happens. The service provider is the application the user wants to reach, and it never sees a password at all, just the signed assertion that stands in for one. Duo's healthcare example shows why that matters: a hospital network sets up SAML so staff log in against the hospital's own identity provider, then get access to outside clinic and insurance systems without their credentials ever leaving the hospital's system. The outside systems see only the assertion, never the password behind it.

Two flows get a user to that assertion. In SP-initiated flow, a user goes straight to the application first and gets bounced to the identity provider to log in before coming back. In IdP-initiated flow, the user starts at the identity provider's own portal and clicks through to the application from there. Both paths end the same way: the service provider receives the signed assertion and grants access.

Because credentials never travel to the service provider, SAML cuts down the credential theft surface across every application it connects. An assertion can also carry more than plain identity: attribute statements can pass along roles or group memberships, and authorization decision statements can pass along limited access decisions, though these extras don't always appear in a standard SSO exchange.

Running SAML well takes upkeep. NinjaOne points out that SAML configuration needs regular review of certificates, metadata, signing settings, and app integrations to avoid outages and access gaps. Certificate expiry or a mismatch during certificate rotation is a common, preventable cause of SSO outages. That maintenance cost traces straight back to what SAML was built for: a browser-based, XML-heavy protocol meant for large-scale enterprise federation. Those same design choices give SAML its strength in that setting and set the limits on where it can go.

The boundaries of where SAML fits

SAML earns its keep in enterprise web federation and in regulated industries, and it struggles outside that lane, in mobile apps, API-driven systems, and machine identity. Those aren't minor quirks to patch around. They follow directly from how the protocol was designed. NinjaOne describes SAML as "common in enterprise SaaS and federated identity environments" and calls it "especially useful when organizations need standards-based access across different domains or vendors."

Its strengths line up with that description. SAML is an open standard, and it has broad support across enterprise identity providers. It federates across domains and vendors at real scale. Regulated industries, healthcare, finance, government, have already accepted it as a compliance pattern, which matters as much as the technical fit does. And its hub-and-spoke model lets one identity provider connect to many service providers without heavy configuration on each new app.

Its limits come from the same source. XML gives SAML a larger attack surface than newer JSON-based protocols simply because there's more structure to parse and more places for a flaw to hide. Mobile support is weak because the browser-redirect flow SAML depends on doesn't translate cleanly into native apps. And SAML has no built-in way to handle API-to-API or machine-to-machine authentication, a gap that matters more every year as more systems talk to each other without a human in the loop.

The obvious response is to migrate to OpenID Connect and leave the limits behind. OIDC is becoming the default choice for new, modern applications. But an enterprise running legacy applications, complex access rules, and compliance programs already built around SAML can't just swap protocols. Migration means you have to revalidate every connected application and retest compliance across the board, and that costs the organization in coordination and risk, not just in engineering hours. For a lot of the enterprise and government world, SAML stays the right tool because it's already load-bearing. New builds tend to reach for something else. So most large organizations land on an identity provider that supports both, and they treat the protocol choice as an implementation detail rather than a permanent commitment.

Centralizing authentication through one identity provider is the right security move, but it also concentrates risk there. Everything federated through that IdP depends on it being configured correctly. Governance around the identity provider itself carries so much weight, a point the governance section below returns to.

The three protocols in enterprise SSO stacks

SAML, OAuth 2.0, and OpenID Connect get treated as competitors sometimes, but they aren't fighting for the same job. Each one handles a different piece of identity, so a mature enterprise stack usually runs all three at once, and each does the part it's actually built for.

The distinction that trips people up most is this: OAuth was built to hand out permissions, not to prove who someone is. It answers "what is this app allowed to do," not "who is this user." Treating OAuth as a login mechanism is a known category error, and it carries real security consequences when teams get it wrong. Duo notes that SSO can run on OAuth or OpenID Connect just as well as on SAML, which confirms again that the capability doesn't belong to any one protocol.

A rough map of the three looks like this: SAML handles enterprise workforce SSO and cross-domain federation. OAuth handles letting a third-party app reach a user's resources without that app ever seeing the user's password. OIDC handles login for modern applications, mobile authentication, and identity checks for APIs. Real enterprise stacks mix all three across layers: SAML connects the corporate identity provider to legacy SaaS tools, OIDC runs login on applications the company built itself, and OAuth governs what outside services can reach through an API. Each protocol does its job in its own layer, avoiding competition with the others.

Machine identity shows the pattern clearly. OIDC has largely replaced SAML for machine-to-machine traffic and automated build pipelines, using short-lived tokens to grant cloud credentials at the moment a workflow runs. That shift happened because SAML's XML assertion model was never built with non-human identity in mind. The protocol a team reaches for follows the kind of access being granted, not a preference for one standard over another.

SAML's core design, keeping credentials with a trusted identity provider and issuing signed assertions that service providers accept as proof, has an echo in how enterprise AI governance is starting to take shape. So instead of letting AI agents reach data across systems directly, a centralized governance layer can issue the access decisions that constrain which agents reach which data, and the organization keeps oversight instead of spreading trust out across every connected tool.

How confusing the capability with the protocol creates governance problems

Treating SAML and SSO as the same thing lets blind spots in identity visibility and access policy grow until they surface as security incidents.

The first failure mode appears in access reviews. A team that believes "we have SSO" means "we have SAML everywhere" may miss that some applications authenticate through a completely different protocol, or through no federated protocol. So access reviews, audit logs, and offboarding checklists can all miss coverage, and no one notices until something goes wrong.

The second failure mode appears during onboarding. A new application gets added on the assumption that SAML will cover both authentication and authorization, but the application actually runs on OAuth. The team has now blended two separate decisions, authentication and authorization, into one assumption that doesn't hold, and the access model built on top of that assumption is unreliable from day one.

Two incidents from early 2026 show what that confusion looks like once it's exploitable. In February 2026, a vulnerability in the open-source identity provider Authentik showed the pattern directly: SAML assertion signatures were checked, but response signatures weren't, or no encryption certificate was configured. That let an attacker inject an unsigned, malicious assertion ahead of the real signed one, which Authentik then processed instead, letting the attacker impersonate any user. The flaw wasn't a bug in the ordinary sense. It was architectural: it was rooted in an incomplete grasp of what SAML's verification model actually demands. In March 2026, Citrix patched a critical SAML vulnerability, rated 9.3 on the CVSS scale, in NetScaler ADC and NetScaler Gateway, affecting appliances set up as SAML identity providers, and the flaw was under active exploitation within days of disclosure. An identity provider configured without a full grasp of its own SAML attack surface becomes a single point of failure for every application it federates to.

The lesson from both incidents is that knowing which protocol runs where, what it's configured to assert, and what each service provider is set up to accept is the baseline condition for knowing what a company's identity infrastructure is actually doing at any given moment. MCPManager's position reflects that same standard applied to AI: visibility into what an authenticated identity, human or AI agent, actually touches only means something if it's real-time and if the access model is understood down at the protocol level, not just described in terms of the broader capability. An audit log that can't say which protocol granted which session is only useful after the fact, for writing up what already happened, not for stopping an incident in progress.

Choosing a Protocol With SAML Already in Place

Picking a protocol comes down to four things: what applications are already in the environment, what identity infrastructure already exists, what compliance rules apply, and what the total cost of running each option looks like over time. It isn't a question of which protocol is better in the abstract.

SAML makes sense when the environment already runs legacy enterprise SaaS tools built around SAML federation, when partners or customers run their own SAML identity providers that can't be changed from the outside, or when the business sits in a regulated sector, healthcare, government, finance, where SAML-based federation is the pattern regulators and auditors already recognize.

OIDC makes sense when a team is building new applications, connecting modern cloud-native services, targeting mobile users, or handling API-based and machine-to-machine identity checks. Its JSON token format and its foundation on OAuth fit those contexts more naturally than SAML's XML model does.

Most large organizations end up choosing both, because most large organizations run a mixed landscape of old and new applications at the same time. The practical move is picking an identity provider that supports both protocols and can route each application to whichever one fits it, rather than forcing every system in the company onto a single standard that was never built to cover all of them.