How to add SSO and SAML to my SaaS Product
This is Part 1 of our series on adding SSO and SAML to your SaaS product. In this part, we cover the business drivers for enterprise SSO, the compliance and security benefits, and the fundamental differences between SSO, SAML, OIDC, and OAuth. In subsequent parts, we will dive into implementation options and a complete Next.js walkthrough.
How do I add SSO and SAML to my SaaS product?
The fastest production path is to pick a managed auth service that exposes SAML as a first-class primitive, model every customer tenant as a per-organization SSO connection, let the customer's IdP admin upload metadata, enable SCIM (Directory Sync) for automated deprovisioning, and test end-to-end against a staging IdP before touching production. With Clerk on Next.js 16 that runs roughly 1–3 hours of code plus IdP round-tripping; building it yourself with the Node.js SAML libraries is realistic at 4–8 weeks for an MVP and 3–9 months production-hardened against the 2025–2026 XML signature and parser-differential CVEs. The walkthrough below covers the full Clerk implementation, side-by-side comparisons with Auth0 and WorkOS, the DIY reality check, and the pitfalls that trip up first-time SAML implementers.
Procurement, not revenue, is the trigger — the moment an enterprise security questionnaire asks whether your product supports SAML 2.0 SSO, the deal hinges on the answer. Ship SAML first because it is the protocol named by name in most enterprise workforce RFPs, then add OIDC or EASIE second for SMB and mobile.
SAML vs OIDC at a glance: the 30-second answer
Before you spend a sprint picking a protocol, here's the short version. If your buyer is a workforce enterprise on Okta, Entra ID, Ping, JumpCloud, or ADFS, ship SAML 2.0. If your buyer is a Google Workspace or Microsoft Entra tenant that doesn't require per-tenant cryptographic isolation, EASIE (multi-tenant OIDC) is the fastest route. If you're authenticating mobile, SPA, CLI, or service-to-service workloads, OIDC is the native fit.
Rule of thumb that fits in one sentence: ship SAML first for enterprise workforce SSO, OIDC (or EASIE) second for SMB and mobile. The three-column breakdown that adds EASIE is in Section 3; the decision tree is further down.
The "going enterprise" inflection point
A SaaS crosses from "growing" to "going enterprise" the moment an opportunity arrives that can't close without SSO. The trigger is procurement, not revenue. That moment can arrive at a $10,000 ACV contract with a company that bought enterprise-grade posture because the champion on the buyer side is a former CISO, or it can wait until a $250,000 ACV mid-market deal. Either way, the question arrives the same way: a PDF called something like "Vendor Security Questionnaire v4.3.xlsx" lands in your inbox, and line 47 asks whether your product supports SAML 2.0 SSO against a list of named identity providers.
If you haven't hit this inflection point yet, the data says you will. SoftwareFinder's 2025 SaaS Security Report measured that 68% of enterprise RFPs now mandate both MFA and SSO in the base plan — not as a premium upcharge — and that 43% of buyers have disqualified vendors for failing to provide verifiable credentials. The same report found that 61% of enterprises and 26% of SMBs require InfoSec sign-off before a software purchase can proceed. The inflection point isn't about company size anymore; it's about vertical and buyer sophistication.
The mechanical cost of not supporting SSO is real. Most vendors who land in procurement without documented SAML support get stuck in security review for additional weeks while InfoSec tries to map their auth model onto the customer's federation standards, and a meaningful share of those vendors never exit the security-review stage at all. The deal doesn't get negotiated down — it gets quietly moved to the "revisit next fiscal year" bucket while procurement finds a competitor who already ships SAML.
Who this guide is for
This article is written for an OAuth-familiar developer. You know the Authorization Code + PKCE flow. You've integrated "Sign in with Google." You understand what a redirect URI, an access token, a refresh token, and an ID token are. You can read a JWT. You have never shipped SAML in production.
You're about to meet a protocol from 2005 that speaks XML, uses HTTP POST to deliver assertions to something called an Assertion Consumer Service, trusts X.509 certificates that your customer's IT admin rotates on a schedule you cannot control, and patches a steady stream of signature-wrapping vulnerabilities that have shipped in production libraries as recently as August 2025. The goal here is to bridge the gap: every SAML concept is introduced by analogy to the OAuth concept you already know, and then the important differences are called out explicitly.
What you'll learn
This guide covers:
- Why enterprise customers mandate SSO and SAML, including the business, compliance, and security drivers that make "we don't support SSO" a deal-killer.
- How SAML differs from OIDC and OAuth, where your existing OAuth knowledge transfers cleanly, and where it doesn't.
- The three real implementation options — build it yourself, use a managed authentication service, or pick a single-purpose SSO gateway — with honest trade-offs and current pricing.
- A complete, production-ready walkthrough for adding enterprise SSO to a Next.js 16 app using Clerk, covering organizations, per-tenant SAML connections, attribute mapping, JIT provisioning, and SCIM-based deprovisioning.
- Side-by-side implementation snippets for Auth0 and WorkOS so you can see where each vendor diverges from Clerk.
- The security pitfalls that still ship in 2026 — XML Signature Wrapping (XSW), parser differentials, IdP-initiated replay attacks, and the certificate-rotation class of failures — and the mitigations you must implement regardless of which auth layer you pick.
- A comprehensive FAQ aimed at the questions procurement, customer IT, and your own team will ask once SAML lands in your codebase.
Why enterprise customers require SSO and SAML
Business drivers: unlocking enterprise deals
The "no SSO, no contract" reality
Enterprise procurement runs on checklists, and SAML is near the top of almost every one of them. The Vendor Security Alliance (VSA) questionnaire and the Shared Assessments SIG questionnaire — the two most common enterprise security intake forms — both ask explicitly whether a vendor supports SAML 2.0 SSO and whether the vendor supports SCIM 2.0 provisioning. The answer is pass/fail at many organizations. SOC 2, ISO 27001, and HIPAA — the three compliance frameworks procurement teams cite most often when describing "enterprise-ready" — all reference SAML and identity management as a standard control pattern, which is why procurement language often collapses "compliant vendor" and "SAML-capable vendor" into the same requirement.
The "SSO tax" debate has hardened buyer expectations. Ed Contreras, CISO of Frost Bank, famously called paying extra for SSO "an atrocity" in a widely cited 1Password blog interview. Rob Chahin's sso.tax catalog has turned the historical vendor practice of gating SSO behind premium tiers into a procurement veto signal. When 1Password, Notion, Tailscale, and others walked back their SSO-tier pricing between 2022 and 2024, they did so because procurement teams were using sso.tax listings to disqualify vendors before sales even got a call back.
Deal velocity and procurement checklists
ACV thresholds that trigger InfoSec review are predictable: under roughly $25,000 ACV you're selling to SMB, at $25,000–$100,000 you're in mid-market, and above $100,000 you're squarely in enterprise. The $50,000 threshold is where a full InfoSec review kicks in at most mid-market buyers (Tomasz Tunguz's SaaS benchmarks data, 2023). Every one of those reviews begins with a security questionnaire, and every questionnaire starts with authentication.
Operationally, the drag from a missing SAML answer on a security questionnaire is measured in weeks, not days: InfoSec has to run a longer vendor-risk assessment, your account executive has to escalate to customer IT, and the contract sits on the security-review bench until someone decides whether SAML is a blocker. That extra time is what turns a quarter-closing deal into a next-quarter problem.
Compliance drivers
SOC 2, ISO 27001, and HIPAA requirements
SOC 2 — Trust Services Criteria CC6.1, CC6.2, and CC6.3 — requires identity verification before granting access, credentialing and deprovisioning processes, and role-based access control with separation of duties. SSO is the standard control pattern auditors expect. The AICPA Trust Services Criteria (2017, revised 2022) frame SSO as a reasonable mechanism to satisfy all three.
ISO 27001:2022 Annex A controls A.5.15 (Access Control), A.5.16 (Identity Management), A.5.17 (Authentication Information), and A.5.18 (Access Rights) collectively mandate centralized identity with auditable provisioning and deprovisioning. A mature SSO integration is effectively the primary evidence artifact auditors want to see.
HIPAA — 45 CFR § 164.312 — requires unique user identification, audit controls, and authentication. The 2025 HIPAA Security Rule NPRM converts "addressable" specifications (including MFA and encryption) to required. HIPAA-regulated customers who buy your SaaS will increasingly demand MFA enforcement at the IdP plus SCIM deprovisioning with a documented 1-hour revocation SLA.
NIST SP 800-63-4 (final, July 31, 2025) strongly promotes phishing-resistant MFA and requires FIPS 140 Level 1+ key storage at FAL2 for federal agency IdPs. If you sell into federal-adjacent buyers, the practical implication is: support SAML with a customer-managed IdP that already meets the FAL2 bar.
GDPR Article 32 obligates risk-based security measures; SSO is a proportionate control for most B2B SaaS, and Schrems II considerations make a European customer's own IdP the cleanest data-flow boundary.
Auditable access and centralized deprovisioning
Every modern audit reviewer wants to know two things: who had access, and when was that access revoked? SAML plus SCIM answers both questions in a single protocol stack. The IdP owns the identity lifecycle, your app receives signed assertions at sign-in and SCIM events when membership changes, and both sides produce an audit trail that satisfies SOC 2 CC7 and ISO A.8.15 logging controls. Compared to per-application offboarding scripts, this is genuinely less work.
Security benefits of centralized identity
Enforcing MFA at the identity provider
Microsoft's Alex Weinert published the benchmark most cited in security conversations: "Your account is more than 99.9% less likely to be compromised if you use MFA." The Verizon DBIR 2024 reported that stolen credentials were the initial action in 24% of breaches, and the 2025 DBIR found that 88% of Basic Web Application Attacks used stolen credentials. Adoption still skews hard by organization size — JumpCloud's compilation of LastPass Global Password Security Report data shows roughly 87% MFA adoption at organizations with 10,000+ employees but only 27% at organizations under 25 employees. Pushing MFA enforcement to the IdP — rather than building it yourself — means every customer's MFA posture is as strong as their IT admin can make it, without your team shipping per-customer policy code.
Instant offboarding when employees leave
The Snowflake breach (UNC5537, mid-2024) is the textbook cautionary tale: approximately 165 customer tenants lacked mandatory MFA, and hundreds of millions of records were stolen from accounts with valid credentials and no federation. Snowflake's response was to make MFA mandatory by October 2024. A SAML plus SCIM integration gets you 90% of the way there automatically — when the employee is deactivated in the customer's IdP, a SCIM event fires to your app within seconds and the user's session is invalidated without your support team getting a ticket.
The cost of saying "we don't support SSO"
The SSO-tax debate has two sides, and both are worth engaging. On one side, sso.tax has catalogued markups that procurement teams find offensive: GitHub Enterprise's historical 425–525% markup for SSO, HubSpot's 5,000%+ SSO tier cliff, Appsmith's 16,567% markup, Webflow's 13,058%. On the other side, Tuple CEO Ben Orenstein put the counter-position plainly: "SSO costs close to nothing after a little automation." Tailscale reversed their SSO-tier pricing in April 2024 with the founder's note: "The SSO tax felt like a mistake." 1Password's business tier has included SSO since 2023.
The right answer for most B2B SaaS in 2026 is to bundle a reasonable number of SSO connections into the mid-tier plan and charge for scale, not for the feature itself. Charging extra for "business-critical security posture" is a procurement red flag that will cost you deals. Not charging enough means the economics don't work when a single customer onboards fifteen subsidiary organizations with fifteen IdPs. The pricing is a product decision, but the feature is not optional.
SSO and SAML fundamentals for OAuth developers
SSO, SAML, OIDC, and OAuth: how they relate
SSO is the goal; SAML and OIDC are two ways to get there. SSO means one login session unlocks many applications. SAML 2.0 is the 2005 XML-over-HTTP standard ratified by OASIS on March 14, 2005. OIDC 1.0 is the 2014 JSON-over-HTTP standard built on OAuth 2.0, finalized by the OpenID Foundation on February 26, 2014. OAuth itself is an authorization protocol, not an authentication protocol — it's the substrate that OIDC rides on top of. When marketing pages say "OAuth login," they usually mean "OIDC-on-top-of-OAuth," but it's worth keeping the distinction straight because it shapes what each token is allowed to do.
Here's the fuller three-column comparison, with the multi-tenant OIDC variant (EASIE) added. EASIE is what differentiates this from every other SAML-vs-OIDC article on the web — multi-tenant OIDC is an option most readers don't yet know exists.
Where OAuth knowledge translates (and where it doesn't)
The mental model you already have for OAuth maps pretty cleanly onto SAML.
Where it breaks down: SAML signatures are XML signatures (XML-DSIG), not JWT signatures — the algorithms and wire formats are different and the class of signature-wrapping vulnerabilities (XSW) is entirely SAML-specific. There is no PKCE in SAML because the browser POST binding that delivers the assertion is not subject to the same code-injection attack surface as OAuth's redirect-based flows. SAML supports an IdP-initiated flow (the IdP starts the exchange and POSTs an unsolicited assertion to your ACS) that has no OAuth analogue; treat it as a distinct attack surface. And finally, Single Logout exists in both protocols and is equally hard to get right in both — most production deployments simply don't implement it.
Why SAML still dominates enterprise IT
Legacy installed base plus IT procurement familiarity. Okta holds roughly 41% of the tracked standalone IAM market on 6sense's public tech-graph dashboard, and Microsoft disclosed more than 610 million Entra ID monthly active users on its FY2023 Q4 earnings call (July 25, 2023) (secondary coverage). Both IdPs support SAML and OIDC first-class. New enterprise IT apps increasingly ship OIDC; inherited apps stay on SAML. If your buyer has a ten-year-old IdP deployment with SAML parsers plugged into Splunk, don't fight the procurement language — ship SAML.
Next steps
Understanding the business drivers and the protocol differences is the first step. You now know why enterprise customers demand SAML and how it compares to OIDC and OAuth. In Part 2, we will explore the real-world implementation options—building it yourself versus using a managed authentication service—and the trade-offs involved.
Frequently asked questions
Do I really need to support SAML if I already have OIDC?
Yes, if you are selling to enterprise workforce customers. While OIDC is growing, many legacy enterprise identity providers and procurement checklists still explicitly require SAML 2.0.
Can I charge extra for SSO?
While historically common (the "SSO tax"), charging a massive premium for SSO is increasingly viewed as a procurement red flag. The modern best practice is to bundle a reasonable number of SSO connections into mid-tier plans and charge based on scale or usage.
Does SAML support mobile apps well?
No. SAML relies on browser POST bindings and XML, which are not well-suited for native mobile apps. For mobile, SPA, or CLI workloads, OIDC (using Authorization Code with PKCE) is the recommended approach.
In this series
- How to add SSO and SAML to my SaaS Product (you are here)
- How to add SSO and SAML to my SaaS Product - Part 2
- How to add SSO and SAML to my SaaS Product - Part 3
- How to add SSO and SAML to my SaaS Product - Part 4