# Enterprise SSO for B2B SaaS: Architecture, Protocols and the Build vs Buy Decision Enterprise SSO for B2B SaaS means supporting SAML 2.0 and OIDC federation per tenant, routing each user to their own identity provider, and automating account lifecycle through SCIM. Most teams should integrate an identity broker rather than build from scratch. The expensive part is not the initial build. It is operating certificate rotation, deprovisioning and fifty-odd IdP quirks for years afterwards. **Key takeaways** - SSO without SCIM will fail enterprise security review. - Tenant-to-IdP routing is an architecture decision, not a login screen decision. - The maintenance burden, not the build, is what you pay a broker to absorb. - Charging separately for SSO increasingly costs you deals. ## Why enterprise deals stall at the security review The deal is agreed. The champion is sold. Then the security questionnaire arrives, and item fourteen asks whether you support SAML 2.0 with SCIM provisioning. Everything stops. This is the moment most SaaS teams first go looking for answers, and it explains why the deadline for SSO is never set by engineering. It is set by a procurement team you have never met. The pressure is structural. Market research from Mordor Intelligence puts the average enterprise application footprint at around 130 SaaS applications (). No IT department can govern access across that estate with individual passwords, so central identity becomes a contract condition rather than a preference. Audit frameworks reinforce it. SOC 2 Type II and ISO 27001 both put weight on access control and timely revocation. A reviewer wants to see that when someone leaves the customer's company, access to your product ends with their directory account, not whenever your support team gets round to it. Username and password authentication cannot demonstrate that. There is a carrot alongside the stick. The same Mordor research attributes reductions of up to 60 percent in password reset and credential-related help desk tickets to centralised SSO. Treat that as vendor-adjacent market research rather than peer-reviewed data, but it is the benefit your buyer's IT lead cares about. ## SAML 2.0 or OIDC: which one your customers will actually demand Teams overthink this. You will need both eventually, so the real question is sequencing. SAML 2.0 carries signed XML assertions, uses X.509 certificates for signing, and moves data over HTTP POST and Redirect bindings. It is old, verbose and still the dominant standard across large enterprises and legacy identity estates. OIDC is an authentication layer on OAuth 2.0, with JSON over REST. Microsoft Entra ID, Okta and Google Workspace all support it and generally prefer it for new integrations. Sequence it against your pipeline. SAML first if your named accounts are Fortune 500 or regulated. OIDC first if your buyers are cloud-native mid-market companies on modern identity platforms. FeatureSAML 2.0OIDC**Payload**Signed XML assertionsJSON over REST**Typical IdPs**Legacy enterprise estates, Active Directory Federation ServicesEntra ID, Okta, Google Workspace**Flow support**SP-initiated and IdP-initiatedSP-initiated, no true IdP-initiated equivalent**Implementation**High complexityModerate complexity**Common failure**Expired X.509 signing certificateToken validation errorsOne flow deserves a flag. In an SP-initiated flow, the user starts at your login screen and you send them to the IdP, so you know a request is in flight. In IdP-initiated SAML, the user clicks your tile inside Okta or Entra ID and the IdP pushes an unsolicited assertion at your endpoint. Enterprise admins love those tiles. Your parser has to handle an assertion it never asked for, which raises the stakes on signature validation and replay protection. ## The half of SSO that teams forget: SCIM and user lifecycle Just-in-time provisioning creates or updates a local user record on the first successful assertion. It is simple, it works, and it is the reason so many teams think they have finished. JIT cannot deprovision anyone. Deprovisioning, by definition, never involves a login. SCIM 2.0 closes that gap. It is a RESTful protocol that lets the customer's identity provider push account creation, profile and group updates, and deactivations to your application in near real time. The direction of travel matters: the IdP calls you, on its own schedule or on an event, with no user present. Picture what happens without it. An employee leaves. IT disables them in Okta on their last afternoon. Your application still holds an active account, possibly an active session, and quite possibly admin rights on a shared workspace. That gap is identity drift, and it is exactly what a security reviewer probes when they ask how quickly revocation propagates. Session policy sits next to SCIM, not instead of it. Short session lifetimes and periodic re-authentication against the IdP limit how long a revoked user can keep working between the revocation event and your system hearing about it. ![Authentication vs SCIM provisioning lifecycle](https://secure-files.proservers.ws/content/01m480xq7xxa22kwv5a4fgc4y5/d79217a28452b28008b543b27d40cfe0e519e38d0ad630cf901c560c2d5c58a7.jpg) ## Multi-tenant architecture: routing a user to the right identity provider This is the genuinely hard engineering, and the part vendor blog posts tend to skim. Before anyone authenticates, you have to work out which organisation they belong to and which identity provider owns them. That is home realm discovery, and the pattern you choose is difficult to change at customer fifty. **Identifier-first login.** The user types an email address, you extract the domain, look up a matching SSO connection, and redirect to that IdP. If no connection exists, you fall back to password login. Flexible, and the usual default for products with a single shared login page. **Vanity subdomains.** The user lands on `tenant.app.com` and the tenant context is fixed before any input. Fewer lookups, cleaner branding, and it works well when customers already think in terms of their own workspace. The cost is routing, certificate and DNS work you now own. **Path-based routing or explicit workspace selection.** A middle ground that keeps one hostname while still pinning context ahead of authentication. Whichever you pick, verify domain ownership before you bind a domain to an SSO connection. Otherwise anyone who signs up with a corporate email address can claim routing for that company's users. Verification is a DNS record check, and it belongs in your admin flow from day one rather than as a later patch. Account linking carries a related risk. If a user already has a local password account and later arrives through a SAML assertion with the same email address, silently merging the two records invites hijacking. Require verified domain ownership or explicit organisation binding before any federated merge. Then there is authorisation. Map IdP attributes and group claims onto roles you control rather than trusting raw group strings from the customer directory. Customers rename groups. They restructure. Your permission model should not break when they do. Finally, remember that an SSO connection is tenant-scoped configuration. It touches your tenancy model, your admin tooling and the way your own support staff access customer accounts for debugging. Design for a customer IT admin who configures it themselves, because that person will never have access to your database. ![Tenant resolution flow diagram for B2B SaaS SSO](https://secure-files.proservers.ws/content/01m480xq7syqewbqdnn1sac38w/dffa50734bd5ae4316413bb2ccee0c9df77eb78692b5d0a62313497af0427e7f.jpg) ## Build or buy: an honest decision framework Scalekit, which sells identity infrastructure, estimates that building multi-tenant SAML and OIDC in-house takes 12 to 16 weeks of combined backend, frontend, QA and DevOps effort, against less than three days to integrate its own product (). That is a vendor estimate from a company selling the alternative, and worth reading as such. It is also directionally consistent with what the work involves. Be clear about what you would actually be buying. Not SAML parsing. Any competent engineer can parse an assertion. You are buying an admin portal for customer IT teams, a certificate lifecycle you do not have to monitor, and tested handling of the behavioural quirks across dozens of identity providers. ApproachExamplesMaintenance burdenBest for**Open-source libraries in your stack**SAML Jackson, Ory Polis, python-saml, Passport strategiesHigh, you own every edge caseOn-premise or air-gapped deployments, strict residency constraints**Identity brokers and overlays**WorkOS, Scalekit, Auth0 OrganizationsLow, vendor absorbs IdP quirksShipping fast on a standard cloud SaaS model**Full auth platform replacement**All-in-one identity platformsMedium, broader surface areaTeams rebuilding authentication anywayThe variables that decide it are commercial more often than technical: - How many enterprise customers do you realistically expect in the next twelve months? Per-connection pricing is cheap at five and uncomfortable at two hundred. - Do you ship on-premise or into air-gapped environments? If the customer's network cannot reach a third-party broker, the decision is made for you. - Is authentication core to your product's value, or a cost of doing business? - Who gets paged when a certificate expires at 2am? The case for building is real in a narrow set of situations: air-gapped or on-premise distribution, hard data residency rules, or an existing platform team with genuine identity expertise. Do not let a vendor talk you out of it when one of those applies. The case against buying deserves equal honesty. You are putting a third party on the critical path of every enterprise login. Per-connection pricing scales with exactly the customers you most want to win, and migrating off a broker later means re-establishing every connection with every customer's IT department. ![Build vs buy decision matrix for enterprise SSO](https://secure-files.proservers.ws/content/01m480xq81nkx2f3691x8td9p5/9420620729dcbc246d08883a5eb8e3cbd631053205fd81abf64eb77b5ebd2e04.jpg) ## Should you charge extra for SSO? Some SaaS vendors gate SSO behind premium enterprise tiers. The site sso.tax () documents the practice across the industry, with listed markups ranging from around 50 percent to several hundred percent over the base plan. Entries change as vendors adjust pricing, so check it before quoting any specific product. Clerk's breakdown of enterprise SSO pricing models covers the cost side (): enterprise connections do carry genuine support and infrastructure cost, and pretending otherwise is naive. What has shifted is how buyers read it. Security teams now treat SSO as baseline hygiene rather than a luxury, and a CISO who sees a line item charging extra for the control that protects their whole workforce will say so in the negotiation. That friction lands in the middle of your sales cycle. The pragmatic middle ground: bundle SSO into a business or enterprise tier priced on seats, capability and support level. Charge for what scales with the value you deliver. Do not charge for the control that keeps everyone safe. ## Implementation checklist and the failures that actually happen SSO is not a feature you ship. It is a system you operate, and the ways it breaks are well documented. FailureWhat goes wrongWhat to do**XML signature wrapping**An attacker alters the assertion structure while leaving the original signature intact, and a loose parser authenticates a rogue identity.Strict schema validation, verify the signature against the exact assertion ID, never hand-slice XML tokens.**Certificate expiry**A signing certificate lapses after one to three years and every user at one customer is locked out at once, with no deploy on your side to explain it.Poll IdP metadata URLs, alert well ahead of expiry, document rollover with each customer.**RelayState open redirect**The post-authentication redirect parameter is manipulated to send users to a phishing page.Allowlist valid internal routes, or bind RelayState to authenticated session state.**Loose JIT account linking**An existing unverified account is silently merged with a new federated identity on matching email.Verify domain ownership and bind to an organisation before linking.**Identity drift**A deactivated user keeps access through a live session or a stale local record.SCIM listeners, short session lifetimes, periodic re-authentication.Before launch, test against real Okta and Entra ID developer tenants rather than a mock IdP alone. Exercise SP-initiated and IdP-initiated flows separately. Force a certificate rollover and confirm nothing breaks. Run a full deprovisioning cycle end to end and watch the session die. Then give your customer's IT admin a self-serve setup flow with a metadata URL, because configuring connections by email attachment does not scale past a handful of accounts. ## What to do in your first thirty days 1. Scope against your real pipeline, not a hypothetical enterprise. 2. Pick your tenant resolution pattern and write it down before anyone opens an editor. 3. Make the build or buy call using the variables above, and record the reasoning. 4. Ship SAML plus SCIM for one design-partner customer, end to end. 5. Generalise from what that first connection taught you. If you are at step two or three and want a second opinion before committing, AWcode's engineering team can review your tenancy model and routing options and tell you where the retrofit costs will land. ## FAQ **Can we ship SSO without SCIM and add it later?**You can, and plenty of teams do to unblock a pilot. Expect security reviewers assessing SOC 2 Type II or ISO 27001 controls to flag the absence of automated deprovisioning, and expect it to block final approval with regulated accounts. **Do we need both SAML and OIDC?**Eventually, yes. Lead with SAML if your pipeline is large enterprise or regulated. Lead with OIDC if your buyers run Entra ID, Okta or Google Workspace and are open to modern integrations. **How long does enterprise SSO take to implement?**Scalekit estimates 12 to 16 weeks of combined backend, frontend, QA and DevOps effort to build multi-tenant SAML and OIDC in-house, against less than three days to integrate its own product. Treat the figures as a vendor estimate and adjust for your own stack. **What does an enterprise security questionnaire actually ask about SSO?**Whether you support SAML 2.0, whether deprovisioning is automated through SCIM, how session lifetime and re-authentication are handled, and how you govern account linking between local and federated identities. **Can we support customers who run their own on-premise identity provider?**Often yes, with caveats. Front-channel SAML redirects travel through the user's browser, so the IdP needs to be reachable by the user rather than by your servers. SCIM is different: the identity provider must be able to reach your endpoints outbound, which is where air-gapped and non-routable environments break down. --- **How this post looks on the live site:** Rendered in a windowed news reader inside the AWcode OS desktop, alongside other posts. --- **Canonical HTML version:** https://awcode.co.uk/news/enterprise-sso-for-b2b-saas-architecture-protocols-and-the-build-vs-buy-decision **About this document:** This is a plain-Markdown mirror of an AWcode.com page, served so that LLMs and agents can read the content without executing the site's retro-OS JavaScript UI. The HTML page at the canonical URL above carries the same content and is also fully indexable. ## Machine-readable Resources for AI agents, LLMs and integrations: - [https://awcode.co.uk/llms.txt](https://awcode.co.uk/llms.txt) — index of markdown mirrors - [https://awcode.co.uk/llms-full.txt](https://awcode.co.uk/llms-full.txt) — every page + post concatenated - [https://awcode.co.uk/sitemap.xml](https://awcode.co.uk/sitemap.xml) — full sitemap - [https://awcode.co.uk/robots.txt](https://awcode.co.uk/robots.txt) — crawl + Content-Signal policy - [https://awcode.co.uk/ai.txt](https://awcode.co.uk/ai.txt) — AI access policy - [https://awcode.co.uk/openapi.json](https://awcode.co.uk/openapi.json) — OpenAPI 3.1 spec - [https://awcode.co.uk/.well-known/api-catalog](https://awcode.co.uk/.well-known/api-catalog) — RFC 9264 / 9727 link set - [https://awcode.co.uk/.well-known/mcp.json](https://awcode.co.uk/.well-known/mcp.json) — MCP discovery - [https://awcode.co.uk/mcp](https://awcode.co.uk/mcp) — MCP server endpoint (POST JSON-RPC 2.0) - [https://awcode.co.uk/.well-known/agent-skills/index.json](https://awcode.co.uk/.well-known/agent-skills/index.json) — Agent Skills index ### Public API — concrete examples - [GET https://awcode.co.uk/api/posts](https://awcode.co.uk/api/posts) — list recent published posts - [GET https://awcode.co.uk/api/posts/how-startup-studios-de-risk-saas-builds-before-the-first-sprint](https://awcode.co.uk/api/posts/how-startup-studios-de-risk-saas-builds-before-the-first-sprint) — fetch one post - [GET https://awcode.co.uk/api/pages/about](https://awcode.co.uk/api/pages/about) — fetch the about page ### Markdown mirrors — concrete examples - [https://awcode.co.uk/index.md](https://awcode.co.uk/index.md) — homepage - [https://awcode.co.uk/about.md](https://awcode.co.uk/about.md) — about page - [https://awcode.co.uk/news/how-startup-studios-de-risk-saas-builds-before-the-first-sprint.md](https://awcode.co.uk/news/how-startup-studios-de-risk-saas-builds-before-the-first-sprint.md) — one news post