SAML vs SSO: Is SAML the Same as Single Sign-On?

No. SAML and SSO are not the same thing.

• SSO (single sign-on) is the outcome: you sign in once and get into many apps.
• SAML (Security Assertion Markup Language) is one protocol that produces that outcome. The identity provider sends the app a digitally signed XML message, called an assertion, that says who you are.
• They can exist separately. SSO can also run on OpenID Connect (OIDC) or Kerberos, and SAML can protect a single app with no SSO involved.

Quick verdict by reader:

If you are…	What to use
A B2B SaaS team selling to enterprises	Support SAML SSO first, then add OIDC and SCIM
Building consumer, mobile, or single-page apps	OIDC. SAML is a poor fit for native apps.
An IT admin connecting workforce apps	Choose per app. Okta and Microsoft Entra ID support both SAML and OIDC.
Studying for CISSP or Security+	SSO is an experience, SAML and OIDC are federation protocols, and OAuth is authorization

What Is the Difference Between SAML and SSO?

Attribute	SSO	SAML
What it is	An authentication outcome (one login, many apps)	An open XML-based federation standard (SAML 2.0, OASIS, 2005)
Relationship	Can be delivered by SAML, OIDC, Kerberos, or WS-Federation	One of several ways to deliver SSO
Scope	The user experience and session across apps	The trusted message exchange between an identity provider (IdP) and a service provider (SP)
Visible to users?	Yes	No
Data format	Depends on the protocol used	XML
Proof of login	A session plus a protocol artifact	A SAML assertion that is signed, and only optionally encrypted
Where it dominates	Every modern app stack	Workforce SaaS, B2B, and partner federation
Main risk	One IdP login unlocks every connected app	Validation bugs in the SP’s SAML code

Is SAML SSO?

“SAML SSO” means SSO delivered through the SAML protocol. It is the most common form of enterprise SSO for browser-based apps. SAML on its own is not SSO, and the two relationships run in both directions:

• SAML without SSO: a single app federates with one IdP. Login is delegated, but nothing is shared across apps.
• SSO without SAML: Google Workspace sign-in (OIDC), a Windows domain login (Kerberos), or an app gallery that uses OIDC for every connection.

How Does SAML Authentication Work During a SAML SSO Login?

This is the SP-initiated flow, which is the recommended default:

1. The user opens an app (the SP), for example, Salesforce.
2. The SP creates a SAML AuthnRequest and redirects the browser to the IdP.
3. The browser delivers the AuthnRequest to the IdP, for example, Okta or Microsoft Entra ID.
4. The IdP authenticates the user with a password plus MFA, or a passkey. If an IdP session already exists, this step is silent, which is what makes it SSO.
5. The IdP returns a signed SAML Response to the browser as an auto-submitted form.
6. The browser POSTs the SAML Response to the app’s Assertion Consumer Service (ACS) URL.
7. The app validates the assertion (see the checklist below).
8. The app grants access and creates its own session.

An SP-initiated SAML login in 8 steps. The password stays at the identity provider; the app only receives a signed assertion.

IdP-initiated login starts at the IdP portal and skips steps 1 to 3. As a result, the app has no InResponseTo value to match against, so an injected assertion is harder to detect. Allow IdP-initiated login only where users actually need it.

See the complete guide: What Is SAML Authentication? How It Works, With Examples

What Is Inside a SAML Assertion?

Below is a trimmed, illustrative SAML Response. Real responses are longer and base64-encoded.

<samlp:Response Destination="https://app.example.com/saml/acs" InResponseTo="_req123">
  <saml:Assertion ID="_a1b2c3" IssueInstant="2026-09-21T14:02:11Z">
    <saml:Issuer>https://idp.example.com</saml:Issuer>
    <ds:Signature>...</ds:Signature>
    <saml:Subject>
      <saml:NameID>maria@corp.example</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData Recipient="https://app.example.com/saml/acs"
          NotOnOrAfter="2026-09-21T14:07:11Z" InResponseTo="_req123"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2026-09-21T14:01:41Z" NotOnOrAfter="2026-09-21T14:07:11Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://app.example.com</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AttributeStatement>
      <saml:Attribute Name="role"><saml:AttributeValue>finance-admin</saml:AttributeValue></saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Read the detailed guide:What Is a SAML Assertion? Structure, Example, and Validation (2026)

Element	What it tells the app
Issuer + Signature	Which IdP vouches for the user, and the cryptographic proof of it
NameID	Who the user is
Audience / Recipient	Which app and endpoint the assertion is meant for
NotBefore / NotOnOrAfter	The short validity window (minutes, not hours)
AttributeStatement	Roles, groups, and department used for authorization inside the app

real signed SAML Response, generated and verified in a local test environment (Python signxml, RSA-SHA256, self-signed certificate). Base64 values are redacted with their real lengths shown.

• What this test shows:

• Only the Assertion was signed. The Reference URI  points at the Assertion’s ID, so the outer Response and its Status sit outside the signature. This is why apps must read identity only from the signed element.
  
• Tampering is caught. Changing the NameID after signing broke the digest, and verification failed. Removing the signature was also rejected.
  

• Signed does not mean private. The assertion was not encrypted, so anyone who can see the traffic can read its attributes. Integrity comes from the signature; confidentiality comes from TLS or an EncryptedAssertion .
  
• The validity window was 5.5 minutes, from 30 seconds before issue to 5 minutes after.

SAML vs SSO vs OAuth vs OIDC vs LDAP vs Kerberos: Which Layer Does Each Cover?

Most confusion comes from comparing things that sit at different layers. SSO is an outcome. The other five are protocols, and each does a different job.

SSO is the experience. SAML is one of four protocols that can deliver it; OAuth, LDAP, and SCIM support SSO but do not deliver it alone.

Term	What it actually is	Layer	Format/artifact	Standard (year)	Typical use	Implementation effort
SSO	The one-login experience	Experience	Varies	None (it is a concept)	All app stacks	Depends on the protocol
SAML 2.0	Federated authentication	Federation	XML assertion	OASIS (2005)	Workforce SaaS, B2B	Medium to High
OIDC	An authentication layer on top of OAuth 2.0	Federation	JSON Web Token (JWT) ID token	OpenID Connect Core 1.0 (2014)	Web, mobile, and consumer login	Medium
OAuth 2.0	Delegated authorization	Authorization	Access token	RFC 6749 (2012)	API access	Medium
LDAP	Directory lookup and bind	Directory	LDAP messages	RFC 4511 (2006)	Querying Active Directory or OpenLDAP	Low to Medium
Kerberos	Ticket-based network authentication	Network	Tickets from a key distribution center (KDC)	RFC 4120 (2005)	Windows domain SSO	Medium
SCIM 2.0	User provisioning	Lifecycle	JSON REST API	RFC 7644 (2015)	Creating and removing accounts in apps	Medium

Implementation effort is an editorial rating that assumes a maintained library or an IdP gallery integration.

OIDC vs SAML: Which Should You Choose?

Both deliver federated SSO, so the choice depends on your clients and your buyers.

• Choose SAML when the app is browser-based, when customers’ enterprise IdPs expect it, or when you need partner federation.
• Choose OIDC for mobile apps, single-page apps, social login, or when you also need API tokens from the same flow. OIDC uses JSON rather than XML and fits native apps with PKCE (Proof Key for Code Exchange).
• Offer both if you sell B2B SaaS. Enterprise buyers commonly ask for SAML, while your own product teams may prefer OIDC.

Take a closer look: SAML vs OIDC: Which SSO Protocol Should You Use in 2026?

SAML vs OAuth: Is OAuth an SSO Protocol?

No. OAuth 2.0 lets an app obtain an access token to call an API on the user’s behalf. It does not by itself define who the user is. “Log in with Google” is OIDC running on top of OAuth. SAML and OAuth solve different problems and often run side by side: SAML for login, OAuth for API access.

Look further into this: SAML vs OAuth: What Is the Difference and Which Should You Use in 2026?

SAML vs LDAP: Does LDAP Give You SSO?

Not true SSO. With LDAP, each app collects the user’s password and checks it against the directory. That gives users the same password everywhere, which is sometimes called “same sign-on,” but not a single sign-on.

SAML keeps passwords at the IdP, so apps never see them. In practice, the two work together: the IdP often uses LDAP or Active Directory as its user store, then issues SAML assertions to apps.

Explore this further: SAML vs LDAP: What Is the Difference, and Which Should You Use in 2026?

SAML vs Kerberos SSO: What Is the Difference?

Kerberos provides SSO inside a trusted network domain. It is the mechanism behind Windows Integrated Authentication in Active Directory. It needs network reach to a domain controller, which makes it a poor fit for internet SaaS.

SAML works over plain HTTPS across organizations, which is why cloud apps use it. Hybrid setups combine the two: a Kerberos login on the domain-joined PC can silently start SAML or OIDC sessions to cloud apps through the IdP.

Which Should You Use: Workforce, Customer, Partner, or API Access?

Scenario	Recommended protocol	Reason
Employees accessing SaaS (Salesforce, Workday, ServiceNow)	SAML, or OIDC if the app supports it	Enterprise IdPs support both, and many enterprise apps list SAML as the primary option
Selling B2B SaaS to enterprises	SAML first, then OIDC, plus SCIM	Security questionnaires ask for SAML and provisioning by name
Consumer or customer login	OIDC	Social login and passkey-first flows
Native mobile or single-page apps	OIDC with PKCE	SAML relies on browser POST redirects
Partner or supplier federation	SAML	Mature cross-organization trust model
Service-to-service or API calls	OAuth 2.0 client credentials	No user is involved, so this is not SSO
On-prem Windows domain apps	Kerberos	Native to Active Directory
Legacy app that only accepts a username and password	LDAP bind, or place it behind an IdP proxy	Not true SSO without a proxy

Is SAML SSO Secure in 2026?

SAML SSO is as secure as the service provider’s validation code. The protocol itself is sound, but 2026 has produced repeated bypasses in the software that parses it.

Why it matters now:

• In the 2026 Verizon Data Breach Investigations Report, vulnerability exploitation became the top initial access vector at 31%, while credential abuse still appeared somewhere in 39% of breaches overall.
• SSO reduces password sprawl, which addresses the credential side. The SAML libraries that deliver SSO are themselves software that can be exploited, which is the vulnerability side.
  
• US federal baseline: NIST SP 800-63C-4, finalized July 31, 2025, defines Federation Assurance Levels (FAL1 to FAL3) for how assertions are protected and presented. Organizations outside the US often use it as a reference model too.

Which SAML Vulnerabilities Hit in 2025 and 2026?

Vulnerability	Affected software	Root cause	Rule that prevents it
CVE-2026-15013	WordPress SAML Single Sign On plugin, up to 5.4.3	The plugin read the signature algorithm from the incoming SAMLResponse, so an attacker could choose which algorithm the verifier used and turn the IdP’s public key into an HMAC secret	Pin the algorithm from IdP configuration
CVE-2026-19842	Same plugin, before 5.4.7	The plugin stored a certificate from an unverified response, which an admin could then promote to the trusted signing certificate	Take trust anchors only from pre-exchanged metadata
CVE-2026-22734	Cloud Foundry UAA v77.21.0 to v78.8.0	Accepted SAML 2.0 bearer assertions that were neither signed nor encrypted	Reject unsigned assertions
CVE-2026-18092	Net::SAML2 (Perl), before 0.86	Read identity fields with document-wide XPath instead of from the signed subtree (XML signature wrapping)	Read identity only from the verified element

Research published in December 2025 showed a full authentication bypass in the Ruby and PHP SAML ecosystems by exploiting parser-level inconsistencies.

What Must a Service Provider Validate in Every SAML Response?

The seven message-level checks behind secure SAML SSO. The checks marked in red were skipped in real 2026 vulnerabilities.

1. Require a signature. The assertion, or the response containing it, must be signed. Reject anything unsigned, including decrypted assertions that carry no signature.
2. Verify against the metadata certificate. Use the IdP certificate from pre-exchanged metadata, never one embedded in the message.
3. Pin the algorithm. Enforce RSA-SHA256 or stronger from your configuration, and reject HMAC and SHA-1.
4. Read only signed data. Take NameID and attributes only from the element the signature verified.
5. Check the addressing. Audience must equal your SP entity ID, and Recipient and Destination must equal your ACS URL.
6. Enforce the time window. Check NotBefore and NotOnOrAfter with a small clock-skew allowance.
7. Match the request. InResponseTo must match an outstanding AuthnRequest for SP-initiated flows.
8. Block replays. Cache assertion IDs until they expire and reject duplicates.
9. Stay patched. Use a maintained SAML library and patch it on the same cadence as internet-facing software.

How Do You Rotate a SAML Signing Certificate Without Downtime?

1. Generate the new signing certificate at the IdP and publish both certificates in the IdP metadata.
2. Import the new certificate at every SP so each trusts old and new at the same time.
3. Switch the IdP to sign with the new certificate on a scheduled date.
4. Test an SP-initiated login for each critical app.
5. Remove the old certificate from each SP after cutover.
6. Set expiry alerts at 30, 14, and 7 days, because an expired certificate breaks login on every connected app at once.

Why Does My SAML SSO Login Fail?

Error	Likely cause	Fix
Invalid signature	IdP rotated its certificate; the app still trusts the old one	Import the new certificate from IdP metadata
Audience mismatch	SP entity ID differs (trailing slash, http vs https)	Make the entity ID an exact string match
Assertion expired or not yet valid	Server clock drift	Sync servers with NTP
InResponseTo mismatch	The session cookie holding the request ID is set to SameSite=Lax, so the browser drops it on the IdP’s cross-site POST	Set that cookie to SameSite=None; Secure
User not found	NameID format mismatch (email vs persistent ID), or no provisioning	Align the NameID format; enable JIT provisioning or SCIM
Redirect loop	ACS URL mismatch, often http vs https behind a load balancer	Register the exact public ACS URL

How Much Does SAML SSO Cost? (The “SSO Tax”)

Many SaaS vendors put SAML SSO only on their top tier. This practice is known as the “SSO tax,” and the community-maintained sso.tax catalog tracks it.

Cost item	2026 data point
SaaS vendors tracked for SSO markups	About 150 vendors as of June 2026, 104 with a computable markup and 44 priced as “contact sales”
Example markup	GitHub goes from $4 to $21 per user per month to add SAML, a 425% increase
IdP licensing (Microsoft)	The Microsoft Entra free tier covers SSO for a limited set of apps; conditional access and SCIM provisioning require P1 at $6/user/month, and identity governance requires P2 at $9/user/month
IdP licensing (Okta)	Okta is $6 to $17/user/month, with a $1,500 annual minimum
Why SAML gets gated more than OIDC	Requesting SAML signals a buyer with an enterprise IdP and a procurement budget, while OIDC social logins often sit on lower tiers

*Verify each price on the vendor’s page before you budget, because tiers change often.

Does SSO Need SCIM as Well?

Yes, for most organizations. SSO controls how users log in. SCIM controls whether their accounts exist in each app. Without SCIM, a user disabled at the IdP can no longer sign in through SSO, but their account and data remain in each app until someone removes them manually.

What Are the Most Common SAML vs SSO Myths?

Myth	Fact
“SAML sends your password to the app.”	The IdP sends a signed assertion. The password never leaves the IdP.
“SAML assertions are encrypted.”	The SAML Web Browser SSO profile requires a signature when the response is sent by POST. Encryption (EncryptedAssertion) is optional.
“OAuth is an SSO protocol.”	OAuth 2.0 authorizes API access. OIDC adds the identity layer needed for login.
“SSO requires SAML.”	SSO also runs on OIDC, Kerberos, and WS-Federation.
“SSO removes the need for MFA.”	SSO concentrates risk into one IdP login. Enforce phishing-resistant MFA, such as passkeys or FIDO2 keys, at the IdP.

What Do Common SAML SSO Terms Mean?

Term	Meaning
Identity provider (IdP)	The system that authenticates users and issues assertions or tokens, such as Okta, Microsoft Entra ID, or Google Workspace
Service provider (SP)	The app that trusts the IdP’s assertion. OIDC calls it the relying party.
Entity ID	The unique name of an IdP or SP in a SAML configuration, usually a URL
Metadata	An XML file in which the IdP and SP exchange entity IDs, endpoints, and signing certificates
ACS URL	The app endpoint that receives the SAML Response
AuthnRequest	The app’s message asking the IdP to authenticate the user
NameID	The user identifier inside the assertion, such as an email address or a persistent ID

What Is the Bottom Line on SAML vs SSO?

SSO is the goal, and SAML is one way to reach it. The right protocol depends on who signs in and what kind of app they use:

1. Selling B2B SaaS to enterprises: ship SAML SSO with SCIM provisioning, then add OIDC for mobile and modern clients.
2. Building consumer, mobile, or single-page apps: use OIDC with PKCE.
3. Running internal IT: choose the protocol per app, and enforce phishing-resistant MFA at the identity provider.
4. Implementing SAML yourself: use a maintained library, run every validation check above, patch it like internet-facing software, and alert before certificates expire.

In practice, the bigger risk is rarely picking SAML over another protocol. It is an app that accepts what the IdP sends without checking it.

Frequently Asked Questions (FAQs)

Is SAML still used in 2026?

Yes. SAML remains a standard integration option in major enterprise IdPs, including Okta and Microsoft Entra ID. It is widely used for workforce SaaS and B2B federation. New consumer and mobile builds usually choose OIDC.

Can SAML and OIDC run on the same identity provider?

Yes. One IdP can issue SAML assertions to some apps and OIDC tokens to others, using the same user directory and the same MFA policy. That setup is the norm in enterprises that run a mix of older and newer apps.

What is WS-Federation, and how does it compare to SAML?

WS-Federation is an older Microsoft-centric federation protocol that can carry SAML-format tokens. You will mostly see it with legacy Active Directory Federation Services (AD FS) and SharePoint deployments. For new integrations, choose SAML 2.0 or OIDC.

Is a SAML SSO login different from “Sign in with Google”?

Yes. “Sign in with Google” uses OIDC with a consumer or Google Workspace account. SAML SSO login usually goes through your employer’s IdP, which enforces company policies such as MFA, device checks, and access revocation.

Do passkeys replace SAML?

No. Passkeys secure the login at the identity provider (step 4 in the flow above). SAML or OIDC still carries the result of that login to each app.

How does shadow AI affect SSO?

The 2026 DBIR reports that 67% of people using unapproved AI services on company devices sign in with non-corporate credentials. Any tool reached through a personal account sits outside SSO, MFA, and offboarding, so the IdP cannot revoke that access.