Default to OpenID Connect for new integrations, add SAML when an enterprise buyer's IT team requires it, and don't build the whole thing from scratch unless you have months to spare. Most B2B SaaS teams should either buy a managed SSO layer or scope a fixed, time-boxed build. The moment a $50,000+ deal is stuck waiting on "do you support SSO?" the answer needs to be on your roadmap this quarter, not next year.
TL;DR:
- Supporting OIDC by default and adding SAML only when specifically requested saves development time and reduces ongoing support burdens.
- Building in-house for enterprise SSO typically takes several months per IdP, with recurring maintenance costs for cert rotations and attribute quirks.
- Supporting both protocols requires careful architecture, including tenant-specific metadata storage, explicit session tokens, and portable configuration formats.
- Implementing a fixed-price, short-term SSO project can deliver a complete solution in two to four weeks, avoiding the risk of scope creep and unexpected costs.
- Enterprise buyers expect SCIM for automated provisioning, and lacking it can cause security review delays even for strong core products.
Table of Contents
- Why SSO for B2B SaaS Matters More Than Most Roadmap Items
- SAML vs OIDC: What Should You Actually Implement?
- Build vs Buy: Timelines, Hidden Costs, and Decision Signals
- Implementation Checklist: Artifacts and Steps to Ship SSO and SCIM
- Architecture and Scaling: Multi-Tenant Routing and Session Design
- Testing, Monitoring, and Keeping SSO Running
- How to Decide: Build, Buy, or Hybrid, Starting Today
- My Experience Shipping SSO: Practical Lessons From Fixed-Price Builds
- Get a Fixed-Price SSO Build Instead of an Open-Ended Engineering Bet
- Documentation and Guides Worth Reading Next
- Sources
- FAQ
Why SSO for B2B SaaS Matters More Than Most Roadmap Items
Enterprise buyers treat SSO as a checkbox that gates the whole deal, not a nice-to-have feature. Security reviews stall, procurement stalls, and the deal stalls, right behind it, when a vendor can't hand over SAML metadata or confirm SCIM support. This is the pattern behind Security Boulevard's ranked guide to SSO and SCIM providers: once your product starts selling to companies with an IT department, SSO and SCIM stop being optional and become table stakes.
Here's what enterprise buyers actually check before signing:
- Protocol support: SAML 2.0 for legacy and regulated environments, OpenID Connect (OIDC) for modern cloud IdPs, sometimes both.
- Provisioning: SCIM support so IT can add and remove users without a support ticket, plus a just-in-time (JIT) fallback for customers who won't set up SCIM.
- Admin self-service: a settings page where an IT admin can paste in metadata and test the connection without emailing you.
- Audit trails and MFA: login events, admin changes, and session data logged somewhere their security team can pull during a review.
- Cert rotation without downtime: IdPs rotate signing certificates, and if your app breaks when that happens, you'll hear about it from an angry admin, not a monitoring alert.
The authentication stack evolution playbook from ScaleKit points out that IdP diversity alone (Okta, Microsoft Entra ID, Google Workspace, Ping, JumpCloud) forces you to design for different attribute shapes and provisioning quirks, not just one integration.
Statistic to plan around: the same ScaleKit research found that missing SSO and SCIM readiness is a recurring reason enterprise deals stall during security review, regardless of how good the core product is.
Budget your first IdP integration at two to six weeks if you're building it yourself, and expect ongoing support load per customer after that. Every new enterprise logo with a nonstandard IdP setup adds a slice of permanent maintenance.
Pro Tip: Ask your sales team which IdP your next three enterprise prospects use before you write a line of code. Building for Entra ID first is a different job than building for Okta first.
SAML vs OIDC: What Should You Actually Implement?
SAML uses signed XML assertions and metadata exchange; OIDC layers identity on top of OAuth 2.0 using JSON web tokens. That difference sounds academic until you're the one debugging a 4,000-character XML blob at 11 p.m. because a customer's IT admin pasted in the wrong metadata file.
SAML is not going away. Large enterprises, government-adjacent buyers, and anyone running legacy identity infrastructure will ask for it by name, and refusing to support it quietly caps your deal size. Microsoft's SAML vs OIDC decision guide frames this plainly: the two protocols serve different enterprise needs, and supporting both lets a B2B SaaS product reach legacy and cloud-native customers alike.
OIDC, meanwhile, is friendlier to build against. Tokens are JSON, libraries are current, and it plays nicely with single-page apps and mobile clients in a way SAML never will, which matters if your web app and mobile clients share an auth layer. Microsoft's own federation documentation for Entra ID customer setups recommends OIDC as the default for new cloud-native apps, while still treating SAML as essential for many enterprise scenarios.
| Factor | SAML 2.0 | OIDC |
|---|---|---|
| Data format | XML assertions | JSON / JWT |
| Typical buyer | Legacy enterprise, regulated industries | Modern cloud-first IT teams |
| Dev complexity | Higher (XML signing, metadata parsing) | Lower (standard OAuth libraries) |
| Mobile/SPA fit | Poor | Strong |
| Enterprise necessity | Often non-negotiable | Increasingly expected but flexible |
Pro Tip: Build your internal identity layer around OIDC first, then treat SAML as a translation adapter in front of it. Rewriting a SAML-first system to support OIDC later is far more painful than the reverse.
Rule of thumb: support OIDC by default for every new customer, and turn on SAML support only when a specific deal requires it. Trying to support both from day one, before you have a real customer asking, is effort spent on a hypothetical buyer.
Build vs Buy: Timelines, Hidden Costs, and Decision Signals
Building enterprise SSO in-house typically takes months for your first IdP integration, and that number rarely accounts for what comes after: each new customer's IdP quirks, each cert rotation, each "why did login break" ticket. ScaleKit's build-vs-buy analysis puts it directly: buying or integrating a bridging layer shortens time-to-onboard and reduces the per-customer engineering overhead that quietly eats an engineering team's roadmap.
Here's what tends to get underestimated when teams build from scratch:
- The first IdP is the easy part. The second, third, and tenth IdP each bring new attribute names, group formats, or metadata quirks nobody documented.
- Cert rotation is a recurring event, not a one-time task. Every customer's IdP rotates signing certs on its own schedule, and a missed rotation means a broken login for real users.
- Support tickets scale with customer count, not with code quality. Even solid SAML code generates admin confusion during setup.
- Compliance reviews ask questions your MVP auth flow was never designed to answer, like session revocation timing or audit log retention.
A managed bridge or protocol layer buys you speed: days to onboard an IdP instead of months, and far fewer recurring tickets, because someone else absorbs the IdP-quirk problem. Building in-house still makes sense when you need deep customization, when compliance requirements demand you own every line of the auth path, or when SSO is becoming a strategic differentiator rather than a checkbox.
Before your next roadmap meeting, run this checklist:
- Do more than two enterprise prospects require SSO to close?
- Can your team commit real weeks, not spare cycles, to the first integration?
- Will you need SAML, OIDC, or both within the next two quarters?
- Do you have someone who owns cert rotation and IdP support after launch?
If you answered "no" to the third question, buy or hire a fixed-scope build, as explained in why brands should use SaaS SEO for sustainable growth and lower costs. If you answered "yes" to all four, building in-house with dedicated ownership starts to make sense.
Implementation Checklist: Artifacts and Steps to Ship SSO and SCIM
Shipping enterprise SSO comes down to a specific set of artifacts and a specific order of operations. Skip a step here and you'll find out during a customer's IT onboarding call, which is the worst possible time.
- Generate your Entity ID and ACS URL first. These are the two values every enterprise IdP admin will ask for before they configure anything on their end.
- Build metadata exchange in both directions. You need to consume the customer's IdP metadata (XML for SAML, a discovery document for OIDC) and expose your own.
- Decide your IdP discovery method. Domain-based routing (matching the user's email domain to a configured IdP) works for most cases; org-slug routing works better when multiple tenants share an email domain.
- Wire up SCIM endpoints for provisioning. Map attributes (name, email, role, department) and define group sync rules before your first enterprise customer asks for automated deprovisioning.
- Write your deprovisioning rule explicitly. When SCIM removes a user, does access revoke immediately, or at next login? Enterprise security teams will ask this directly.
- Design account linking. Decide what happens when a user's SSO identity doesn't match an existing account, and map license entitlements to SSO groups so seats reconcile automatically.
- Build the admin self-service setup flow. A page where an IT admin pastes metadata and runs a test connection saves you a support ticket every single time.
- Write a support runbook before launch, not after. Cover the five most common failure modes: expired certs, clock skew, attribute mismatches, wrong ACS URL, and stale metadata caches.
- Test in staging with signed assertions and real sample metadata, exactly like a real customer's IdP would send it, before you ever touch production.
Pro Tip: Keep a fixture library of sample metadata from Okta, Entra ID, and Google Workspace in your test suite. Real IdP quirks show up in fixtures you build once and reuse for every new customer.
Architecture and Scaling: Multi-Tenant Routing and Session Design
Where you put your SSO logic determines how much pain your team feels a year from now. A dedicated auth service, separate from your core application logic, tends to age better than SSO code scattered across route handlers, because it isolates the one component that changes per customer.
Multi-tenant SaaS adds a routing problem on top of the protocol problem: given a login attempt, how does your system know which customer's IdP configuration to use? Most teams solve this with either email-domain matching or an org-slug in the login URL, and the choice affects everything downstream, from tenant isolation to how you cache per-tenant secrets.
A few architectural decisions matter more than they look:
- Store per-tenant IdP metadata and certificates in a structure you can rotate without a deploy, since cert rotation happens on the customer's schedule, not yours.
- Design session tokens to carry tenant context explicitly, so a token issued under one org can never be silently accepted by another.
- Cache metadata fetches with a sane TTL. Hitting a customer's IdP metadata endpoint on every login request adds latency and a new failure point.
- Export your SSO configuration in a portable format. If you ever migrate identity providers internally or move to a managed layer, you want your tenant configs in a format you can re-import, not locked in a proprietary schema.
Vendor lock-in shows up here more than anywhere else in the stack. If your internal auth service speaks standard SAML and OIDC at its boundaries, swapping what's behind those boundaries later is a refactor, not a rewrite.
Testing, Monitoring, and Keeping SSO Running
A staging test matrix with signed assertions and real sample metadata catches the failures that would otherwise show up as production tickets. ScaleKit's build-vs-buy research recommends exactly this approach to reduce onboarding tickets and avoid outages tied to a customer's first login attempt.
At minimum, track:
- Assertion validation success and failure rates, broken down by customer.
- Login latency from redirect to authenticated session.
- Certificate expiration dates across every connected IdP, with alerts well before rotation day.
- SCIM sync failures and attribute mapping mismatches.
Statistic to plan around: enterprise procurement teams increasingly treat missing SCIM and audit logging as an automatic red flag during security review, based on the same Security Boulevard analysis cited earlier. Plan ongoing support time, not just launch time, into your capacity model.
How to Decide: Build, Buy, or Hybrid, Starting Today
Three signals should drive this decision: how many active deals are blocked on SSO right now, how much dedicated engineering time you can commit for the next quarter, and whether your compliance posture requires you to own the auth code directly.
- If SSO is blocking live deals and you have no spare engineering capacity, buy a managed layer or hire a fixed-scope build this quarter.
- If you have committed engineering weeks and expect dozens of enterprise customers, build in-house with a dedicated owner for maintenance.
- If you're unsure which IdPs you'll need, default to OIDC now and defer the SAML decision until a real deal requires it.
Pro Tip: Put "SSO decision: build vs buy" on the agenda as its own item, not buried inside a general roadmap review. It deserves a dedicated 30 minutes, because the wrong default quietly costs months later.
My Experience Shipping SSO: Practical Lessons From Fixed-Price Builds
One SAML integration I handled had a customer's IdP sending group attributes in a format their own documentation didn't match. I scope fixed-price SSO builds by freezing the protocol list and IdP targets at kickoff, no drift mid-project. Owning the code from the first commit means the next engineer, mine or theirs, can actually read what shipped.
— Hanad Kubat
Get a Fixed-Price SSO Build Instead of an Open-Ended Engineering Bet
Hanad Kubat is the alternative to hiring a full team or gambling on a slow in-house SSO build: a fixed-price engagement, two to four weeks, with the code owned by your company from the first commit. If your roadmap has "SSO" sitting there unscoped, or your prototype from a no-code tool stalled right at the login wall, that's exactly the kind of problem this work solves. Every line gets written by one senior engineer, no juniors, no surprise invoices after scope is frozen at kickoff. Hiring in-house makes sense when you have committed capacity and a long list of IdPs ahead; hiring for a fixed-scope build makes sense when a deal is stuck now and you need it working in weeks, not months. Check current pricing and start a project at Hanadkubat, and if security requirements are part of what's blocking the deal, this SaaS security requirements plan is worth reading alongside it.
Documentation and Guides Worth Reading Next
- Microsoft's SAML vs OIDC decision guide for protocol tradeoffs.
- Your target IdP's own federation docs before onboarding any single customer.
- SaaS security checklist for B2B teams for the compliance layer around SSO.
FAQ
Should I Build SAML Support if My Customers Use Only OIDC IdPs?
No. Support OIDC first and add SAML only when a specific enterprise deal requires it. Building SAML speculatively, before a customer asks, is engineering time spent on a hypothetical buyer.
How Long Does It Take to Add SSO to an Existing SaaS Product?
An in-house build typically takes months for the first identity provider, according to ScaleKit's build-vs-buy research, with ongoing maintenance for each new customer after that. A fixed-price build runs two to four weeks with scope frozen at kickoff.
Is SCIM Required Alongside SSO for Enterprise Deals?
SCIM isn't always contractually required, but enterprise IT teams increasingly expect it because it automates provisioning and deprovisioning without manual tickets. Skipping it often shows up as friction during security review, per Security Boulevard's enterprise SSO analysis.
What Does It Cost to Get SSO Built for My SaaS Product?
Pricing depends on scope; exact scope and pricing for an SSO-specific build are available on the provider's website. Exact scope and pricing for an SSO-specific build are available at Hanadkubat.
Can I Support Both SAML and OIDC Without Doubling My Maintenance Work?
Yes, if you build your internal identity layer around one standard, usually OIDC, and treat SAML as a translation adapter in front of it rather than a parallel system. This keeps most of your maintenance work in one place instead of two.