A common moment in B2B SaaS engineering: an enterprise prospect declares that they require “SAML SSO” before signing the contract. The documentation that follows is dense with XML schemas, OASIS specifications, and a stack of acronyms (SP, IdP, ACS, AuthnRequest, SLO). The question of what to actually build and whether SAML is even the right call, instead of using an existing OIDC integration, gets lost in the terminology.
\nThis article is written for backend and full-stack engineers at B2B SaaS companies who need to add enterprise SSO to unblock a deal. The goal is to make the underlying protocols legible, without reverse-engineering them from vendor docs.
\nThe single most important sentence to internalize:
\nSAML is not the same thing as SSO. SSO is the goal. SAML is one protocol that gets you there.
\nEverything else in this article follows from that distinction.
\nSSO (Single Sign-On) is an authentication strategy that lets a user log in once with one identity provider and access multiple applications without re-authenticating. It is a user-experience pattern, not a protocol. SAML, OIDC, OAuth, and Kerberos are all things that can be used to implement SSO. They are not synonyms for it.
\nThe mechanics are conceptually simple:
\nConsumer SSO is familiar from daily life. Logging into Google grants access to Gmail, Drive, Calendar, and YouTube under a single session. The B2B version is structurally identical, but the IdP is a corporate identity platform. A marketing analyst at a Fortune 500 logs into Okta once in the morning, and from that single session can launch Salesforce, Slack, Workday, Zoom, and the SaaS product being purchased, without typing another password.
\nThat second example is the one that matters for revenue. When an enterprise IT team states an SSO requirement, the meaning is specific: employees should be able to access the product through the corporate identity platform, with offboarding, access reviews, and audit logs flowing through the same system that handles every other application. That is the requirement. SAML is one way to fulfill it. OIDC is another.
\nThe benefits stack quickly: one set of credentials to rotate, MFA enforced centrally, instant deprovisioning when an employee leaves, and a single audit log to satisfy compliance. These benefits do not come from SAML specifically — they come from SSO as an architecture. SAML is just the message format that some enterprises happen to insist on.
\nSecurity Assertion Markup Language (SAML) is an open XML-based standard for exchanging authentication and authorization data between an Identity Provider and a Service Provider. SAML 2.0, ratified as an OASIS Standard in March 2005, is the version meant whenever SAML is discussed today. SAML 1.1 still exists in legacy environments, but new integrations should never be built against it.
\nSAML has three core building blocks worth understanding before any code gets written:
\n<AuthnRequest> to the IdP, the IdP responds with a signed <Response> containing an assertion. Other protocols defined in SAML 2.0 include Single Logout, Artifact Resolution, and Name Identifier Management.AuthnRequest from SP to IdP) and HTTP-POST (used to deliver the signed Response back to the SP). A SOAP binding exists for back-channel communication, and an Artifact binding exists for higher-security flows.Trust between the SP and IdP is established through metadata exchange: an XML file containing endpoint URLs, supported bindings, and the X.509 public certificate that the SP will use to verify the IdP’s signatures. These metadata files (or URLs that serve them) are exchanged during the initial configuration of every SAML connection.
\nThe major SAML IdPs encountered in enterprise integrations are Microsoft Entra ID (formerly Azure AD), Okta, Google Workspace, Ping Identity, OneLogin, and Active Directory Federation Services (ADFS). When an enterprise customer states a SAML SSO requirement, one of these is almost certainly the IdP in use.
\nThe cleanest way to think about it: SSO is the destination. SAML is one of the routes.
\nA comparison table makes the asymmetry explicit:
\n| \n | SSO | \nSAML | \n
|---|---|---|
| What it is | \nAn authentication strategy or goal. | \nAn open protocol / message format. | \n
| What it defines | \nThe user experience of “one login, many apps.” | \nThe structure and exchange of identity messages. | \n
| Existence | \nCan be implemented without SAML, by using OIDC, Kerberos, or proprietary protocols. | \nOnly makes sense in the context of SSO. | \n
| Governance | \nDetermined by architecture and product choices. | \nGoverned by the OASIS open standard. | \n
| Typical context | \nAny multi-application environment. | \nEnterprise B2B, federated identity, legacy systems. | \n
The takeaway: not all SSO is SAML, but all SAML is SSO. A competitor’s homepage that says “this product supports SSO” reveals nothing about which protocol is implemented. A claim of “SAML SSO” support is specific. It means the product speaks the XML-based OASIS standard that enterprise IT teams expect.
\nSo the next question is the one that actually matters: how does SAML implement SSO in practice?
\nSAML SSO has two flows. Both will eventually need to be supported. Understanding one well first is the path to handling both.
\nThis is the flow that runs when a user clicks “Log in” on the application:
\n<AuthnRequest> (typically via HTTP-Redirect binding, with the request encoded in the URL).<Response> element.NotBefore and NotOnOrAfter timestamps, confirms the Audience matches the application’s entity ID, and verfies the InResponseTo attribute matches the original AuthnRequest.The second flow starts at the IdP instead of the application. The user logs into the Okta dashboard, sees a tile for the application, clicks it, and the IdP pushes a SAML response to the ACS URL without any prior AuthnRequest.
This is the flow that powers the “app launcher” tiles enterprise users see inside Okta or Entra ID portals. It is also the flow that quietly creates the most security headaches, because there is no AuthnRequest to bind the response to. The application receives an unsolicited assertion and has to decide whether to trust it. This is a real attack surface. Without an InResponseTo value to validate against, the only defenses are signature, audience, and replay protection. The mistakes section below covers this in more detail.
A question every enterprise customer will eventually ask: “When a user logs out of Okta, do they get logged out of the application too?”
\nSingle Logout (SLO) is the SAML protocol designed to answer “yes.” When the user signs out at the IdP, the IdP sends a <LogoutRequest> to every SP that has an active session, and each SP terminates its local session. In theory, the user is logged out everywhere simultaneously.
In practice, SLO is one of the messiest parts of SAML. Implementations vary widely between IdPs. Some send LogoutRequests synchronously and wait for responses, others fire and forget. Browser session state, cookies, and back-channel versus front-channel logout each behave differently. Most B2B SaaS teams ship SP-initiated SSO first and defer SLO until an enterprise customer files a security review finding about it. That is a defensible sequence, but the conversation is coming. Not implementing SLO means a user who logs out of an IdP can still walk back into the application on the same browser if the session cookie is alive.
\n