This article is written by the team that builds Casdoor, so we are not neutral, and we say where we think Casdoor fits and where it doesn't. Facts about other products come from their own websites as of November 5, 2026 (listed under Sources) and may have changed. Spotted something out of date? Tell us.
People use "SSO" and "SAML" as if they were the same thing. They are not: one is a result, the other is a way to get there.
Short answer: SSO (single sign-on) is the capability of signing in once and reaching many applications without another password prompt. SAML 2.0 is one protocol that implements browser SSO by passing signed XML assertions between an identity provider and a service provider. You can have SSO without SAML (OIDC, CAS, Kerberos) and you can use SAML for something other than a full SSO program.
What SSO actually means
SSO is a user experience and an architecture. The user authenticates to one identity provider, and that provider vouches for the user to every application that trusts it. The applications do not each keep a separate password; they accept the provider's assertion or token and create their own session.
The value is not only fewer passwords. SSO centralizes MFA, account disablement, access reviews and audit logs. When an employee leaves, disabling one identity provider account should cut off every connected application.
SSO does not define which protocol is used. That is the part people confuse with SAML.
What SAML actually is
SAML 2.0 is an OASIS standard for exchanging authentication and authorization data. In the browser SSO profile:
- The user opens an application (the service provider, or SP).
- The SP sends a SAML request to the identity provider (IdP).
- The IdP authenticates the user.
- The IdP posts a signed XML assertion back to the SP's assertion consumer service URL.
- The SP validates the signature, audience, recipient and expiry, then starts a session.
SAML is verbose, XML-based and built around browser redirects and POSTs. It is also extremely widely supported in enterprise software, which is why it is still the default for workforce SSO.
SSO vs SAML at a glance
| SSO | SAML 2.0 | |
|---|---|---|
| What it is | A login experience and an architecture | A protocol and a data format |
| What it defines | One identity provider, many trusting applications | Requests, assertions, bindings, metadata, signatures |
| Alternatives | OIDC, CAS, Kerberos, header-based SSO | No; SAML is one option among several |
| Typical buyer question | "Can our employees use one login?" | "Does the application support SAML?" |
| Failure mode | A user cannot reach an app after signing in | A certificate, entity ID or attribute mapping is wrong |
The terms meet in the phrase SAML SSO: single sign-on implemented with the SAML protocol. It is accurate, but it names the tool rather than the outcome.
Where OIDC fits
OpenID Connect is the other main browser SSO protocol. It runs on top of OAuth 2.0 and uses JSON Web Tokens instead of XML assertions. New consumer and SaaS applications usually implement OIDC first, and many enterprise applications now support both SAML and OIDC.
The practical difference is not "which is more secure" in the abstract. Both can be deployed safely or badly. The differences are ecosystem and operations: SAML has broader coverage in older enterprise software, while OIDC is easier to implement in modern web and mobile stacks and has a simpler discovery model. See SAML vs OIDC for the protocol comparison.
Where CAS and Kerberos fit
CAS is another browser SSO protocol, common in universities and older Java applications. Kerberos is a ticket-based authentication system used inside Windows and Active Directory estates. Both can deliver SSO, and neither is SAML.
This is why "we use SSO" is not a complete answer in a vendor questionnaire. The next question is always "with which protocol?".
Does SSO use SAML?
Sometimes. SSO is the goal; SAML is one implementation. A company may run:
- SAML SSO for Salesforce, Workday and other enterprise SaaS.
- OIDC SSO for its own web applications and mobile apps.
- CAS for a legacy university application.
- Kerberos for desktop sign-in inside Active Directory.
All of these are SSO from the user's point of view. Underneath, they are different protocols with different metadata and different failure modes.
Which term should you use?
- With business stakeholders: SSO. It describes what they get.
- With application vendors: SAML, OIDC or CAS. Ask which protocol and which version.
- In a security review: name the protocol and the flow, not just "SSO".
- In a support ticket: include the protocol, the SP entity ID and the ACS URL; that is what makes the ticket actionable.
How Casdoor fits
Casdoor is an open-source identity provider that supports SAML 2.0, OpenID Connect, OAuth 2.0, CAS and LDAP from one deployment. That means one user directory can provide SAML SSO to an enterprise application, OIDC SSO to a modern app and CAS to a legacy system, without running three separate identity servers.
For the setup side, see setting up Casdoor as a SAML IdP and SAML attribute mapping. Casdoor is self-hostable for free; Casdoor Cloud starts at $9 per month for a dedicated instance with no per-user fees.
Related reading: what single sign-on is, what SAML is, identity provider vs service provider and OAuth vs SAML vs OIDC.
Sources
- OASIS: SAML 2.0 technical overview
- OpenID Connect Core 1.0
- RFC 6749: The OAuth 2.0 Authorization Framework
- Casdoor docs: Single sign-on
- Casdoor docs: SAML
Product names are trademarks of their respective owners.