SSO vs SAML: What Is the Difference for IT Teams?

Short answer: SSO vs SAML is not a choice between two options. Single sign-on (SSO) is the outcome: a user signs in once and reaches many applications. SAML (Security Assertion Markup Language) is one protocol that delivers that outcome, by having an identity provider send a signed XML assertion to each application. You can have SSO without SAML, but SAML exists to provide SSO.

SSO vs SAML at a glance

What SSO means

Single sign-on is an access experience, not a technology. Microsoft describes SSO in Entra ID as letting users "sign in once and reach many applications" with one set of credentials (Microsoft Learn). The identity provider verifies the user once, then vouches for that user to each app.

For IT teams, the value of SSO sits in the identity provider: one place to apply sign-in policy and one account to disable at offboarding. The protocol that carries the result to each app is a separate, per-app decision.

How SAML delivers SSO

In SAML terms, the identity provider (IdP) authenticates the user and issues an assertion, and the service provider (SP), meaning the application, relies on that assertion to grant access (OASIS). A typical SP-initiated SAML sign-in runs like this:

1. User opens the app. The app has no session, so it builds a SAML authentication request.
2. Redirect to the IdP. The browser carries the request to the identity provider, for example with the HTTP Redirect binding.
3. IdP authenticates. The IdP checks credentials and policy, or reuses an existing session.
4. Assertion returned. The IdP sends the assertion back through the browser inside an HTML form (the HTTP POST binding).
5. App grants access. The app validates the assertion and reads the user's identifier and attributes.

Step 3 is where SSO happens. When the user opens a second SAML app, the IdP already has a session and does not ask for the password again.

SP-initiated vs IdP-initiated SAML

OASIS describes two starting points for the SAML Web Browser SSO profile. SP-initiated sign-in starts when the user opens the app and is sent to the IdP. IdP-initiated sign-in starts when the user signs in at the IdP first, for example from an app portal, and then opens the app (OASIS). When an app supports both, test both paths during onboarding.

Other ways to get SSO without SAML

SSO does not require SAML. Microsoft Entra ID documents these options (Microsoft Learn):

• SAML 2.0: XML-based federation that Microsoft says suits traditional web apps and cases that need detailed user attributes.
• OpenID Connect: federation built on OAuth 2.0 with JSON-based tokens, suited to modern web apps, mobile apps and APIs.
• Password-based SSO: the IdP stores the app credentials and replays them, for apps without federation support.
• Linked SSO: a link in the user portal only, used during phased migrations; it is not true SSO.

Watch out: with password-based and linked SSO the app still has its own credentials, so check how access is removed from that app when a user leaves.

Common misconceptions about SSO and SAML

• "Do we need SSO or SAML?" The real question is which protocol a given app supports for SSO.
• "SAML means MFA." MFA is a policy enforced by the identity provider. SAML only carries the result of sign-in.
• "SAML creates user accounts." SAML signs users in. Creating and removing accounts is provisioning, often done with SCIM, and is configured separately.
• "A tile in the portal means SSO." Linked SSO shows a tile without federated sign-in, as Microsoft's documentation notes.

When SAML is the right way to deliver SSO

SAML is the right choice for an app's SSO when:

• The app offers SAML and not OpenID Connect, which you confirm in the vendor's admin documentation.
• You need detailed user attributes passed at sign-in, the case Microsoft highlights for SAML.
• The app is a traditional browser-based web app rather than a mobile or API-driven app.

Microsoft's guidance for administrators is that both SAML and OpenID Connect work with an identity provider, though SAML "might fit established enterprise systems better."

Admin tip: before buying a SaaS app, ask the vendor which SSO protocols it supports, which plan includes SSO, and whether user provisioning is included or sold separately.

Bottom line

Treat SSO as the goal and SAML as one connector that gets you there. When you onboard an app, use the federation protocol it supports best, keep sign-in policy in the identity provider, and set up provisioning separately. To compare identity providers that deliver SSO over SAML and other protocols, start with the single sign-on software category or build a list with the software shortlist tool.