Enterprise Authentication & SSO in SaaS: A Technical Guide for Founders

Authentication is the first technical question your enterprise prospect will ask — and the first place you can lose the deal.

You are building a SaaS product. The product works, the demo goes well, and then the IT manager or security lead asks: “Do you support SSO?” If the answer is no, or “we’re working on it,” the deal is often over. Not because they are being unreasonable, but because enterprise IT departments are responsible for controlling access to every system their employees touch. A product without SSO is a security gap they cannot explain to their CISO.

This guide is written for technical founders and senior engineers who are either building enterprise SaaS from scratch or who have a product already in market and need to move upmarket. It covers the full authentication stack: basic auth to SAML to SCIM, build vs buy tradeoffs, real cost numbers, and what the security questionnaire will actually ask.

If you want to understand how authentication fits into the broader architecture of a SaaS product, read the SaaS platform architecture decisions guide first.

---

The Authentication Spectrum in SaaS

Authentication requirements grow with your customer size. Most SaaS products evolve through three distinct tiers.

Tier 1: Basic Authentication (0–50 seat customers)

• Email and password — the default. Users create accounts with an email address and a password you store as a bcrypt or Argon2 hash. Never MD5, never plain text, never SHA-1.
• Social login — Google OAuth2, GitHub OAuth, LinkedIn. Delegated authentication via OAuth2 authorization code flow. The user authenticates with the provider and your application receives an access token and an ID token. You store the provider’s user ID, not a password.
• Magic links — passwordless email-based login. A time-limited signed token sent to the user’s email, exchanged for a session. Simple to implement, good UX for low-frequency SaaS tools.

At this tier, session management is straightforward: issue a signed JWT or an opaque session token, store it in an HttpOnly cookie, expire it after 24–48 hours, done.

Tier 2: Growth Authentication (50–200 seat customers)

• TOTP-based MFA — Time-based One-Time Passwords via Google Authenticator, Authy, or any RFC 6238 compatible app. Users enroll by scanning a QR code that encodes a shared secret (base32-encoded, 160-bit minimum). At login, they enter a 6-digit code that your server validates against the current 30-second window.
• SMS-based MFA — easier for users, weaker security. SIM swapping is a real attack vector. Use TOTP instead whenever possible, and treat SMS as a fallback, not a primary MFA method.
• Session management — at this scale you need to think about concurrent sessions, session revocation, and activity-based expiry. A user changing their password should invalidate all existing sessions.
• Audit logs — who logged in, from where, when. Enterprise procurement will ask for this.

Tier 3: Enterprise Authentication (200+ seat customers)

This is the tier where deals get won or lost. The requirements here are:

• SAML 2.0 — the XML-based federation protocol used by legacy and mid-market enterprise IdPs
• OIDC (OpenID Connect) — the modern JSON/JWT-based identity protocol built on OAuth2
• SCIM 2.0 — automated user provisioning and deprovisioning
• Directory sync — real-time group membership sync from Azure AD or Okta
• Admin-enforced MFA — not just “users can enable MFA” but “your IT admin can require it for the entire organization”
• Just-in-time provisioning — create accounts automatically on first SSO login, without pre-provisioning

---

SAML vs OIDC: A Real Technical Explanation

Both SAML 2.0 and OIDC serve the same purpose — federated identity — but they differ in age, format, and adoption patterns.

SAML 2.0

SAML (Security Assertion Markup Language) was standardized in 2005. It uses XML assertions passed between three parties: the user’s browser, your application (the Service Provider, SP), and the customer’s identity provider (IdP like Okta, ADFS, or Azure AD).

The SP-initiated flow:

1. User hits your login page and enters their work email
2. Your application identifies the domain (company.com) and redirects the browser to the customer’s IdP with a SAMLRequest (a base64-encoded, optionally signed XML document)
3. The IdP authenticates the user (or uses an existing session), generates a SAMLResponse containing assertions about the user’s identity, group memberships, and attributes
4. The IdP POST-redirects the browser back to your Assertion Consumer Service (ACS) URL with the SAMLResponse
5. Your application validates the signature on the response against the IdP’s X.509 certificate, extracts the NameID and attributes, and creates a session

SAML metadata documents (XML files describing endpoints and certificates) are exchanged during setup. This is why SAML setup involves “uploading metadata” — your customer uploads their IdP metadata to your application, and you give them your SP metadata to configure on their side.

Who uses SAML: On-premise Okta orgs, Microsoft ADFS, PingFederate, Shibboleth, Oracle Identity Manager. Most enterprises with IT infrastructure older than 2018.

OIDC (OpenID Connect)

OIDC is built on top of OAuth2 and uses JWT tokens instead of XML. It was finalized in 2014 and is the default for modern cloud-native identity providers.

The authorization code flow:

1. User clicks “Sign in with SSO”
2. Your application redirects the browser to the IdP’s /authorize endpoint with response_type=code, scope=openid profile email, a redirect_uri, and a state parameter (CSRF protection)
3. The IdP authenticates the user and redirects back with an authorization code
4. Your backend exchanges the code for tokens at the IdP’s /token endpoint: an access_token, a refresh_token, and an id_token
5. The id_token is a signed JWT containing the user’s identity claims. Your application validates the signature against the IdP’s JWKS (JSON Web Key Set) and extracts sub, email, name

Who uses OIDC: Modern Okta cloud orgs, Azure AD (Entra ID), Google Workspace, Ping Identity cloud, Auth0 as IdP. New enterprise setups in 2024+ almost always prefer OIDC.

Which to implement first?

SAML, for maximum compatibility. Then OIDC. In practice, enterprise deals in 2026 are roughly 55% SAML, 45% OIDC. If you use WorkOS, Clerk, or Auth0, they abstract this entirely — you get a single integration that handles both protocols behind the scenes.

---

What SCIM Is and Why It Matters

SCIM stands for System for Cross-domain Identity Management. It is an HTTP API standard (RFC 7642, 7643, 7644) that lets identity providers manage user accounts in external systems programmatically.

Without SCIM, your customers manage users in two places: in Okta (their source of truth) and in your application. When an employee joins, someone has to manually add them to your SaaS. When an employee leaves, someone has to remember to remove their account. At 10 users this is fine. At 500 users it becomes an audit finding.

With SCIM, your application exposes a standardized REST API. The customer’s Okta or Azure AD instance calls your SCIM endpoints to:

• POST /scim/v2/Users — create a user when they join the company
• PATCH /scim/v2/Users/{id} — update attributes (name, department, manager)
• DELETE /scim/v2/Users/{id} or PATCH with active: false — deprovision when they leave
• GET /scim/v2/Groups — sync group memberships

The deprovisioning piece is what CISOs care about. Terminated employee access being revoked automatically, within minutes of the HR system updating, is a core security control.

Do you need SCIM? Yes, if you are selling to companies with 200+ seats or if your target buyers include IT/security stakeholders. No, if you are selling to small teams where the owner manages their own user list.

---

Build vs Buy: Auth0, Clerk, WorkOS, Okta, and Custom

This is the decision that will shape your engineering roadmap for 2–3 years. Get it wrong and you either overpay, or you spend a quarter rebuilding auth.

Clerk

Best for: B2C or early B2B SaaS, strong developer experience, fast time to production.

Clerk provides a full authentication UI (pre-built components), user management, and basic SAML/OIDC SSO. The developer experience is excellent — drop in <SignIn /> and you have a login page in an afternoon.

Pricing: Free tier is generous. The Enterprise plan (which includes SSO) starts around $100/month and scales per MAU. At 5,000 MAU with enterprise features you are paying roughly $200–400/month.

Limitation: SCIM support is newer and less battle-tested. For deep enterprise requirements, you will hit the ceiling.

Auth0 (Okta)

Best for: Teams that need maximum protocol flexibility and have budget.

Auth0 supports every protocol, every IdP, and every use case. The configuration surface is enormous, which means flexibility but also complexity. The rules/actions pipeline lets you inject logic into any authentication step.

Pricing: The free tier covers 7,500 MAU. The Business plan starts at around $800/month. Enterprise plans with advanced security features run $1,500–4,000/month. SAML connections are an Enterprise feature — this is a common gotcha for teams that start on the free tier.

Limitation: Expensive at scale. Complex to configure correctly. Organizations can become deeply coupled to Auth0 quirks.

WorkOS

Best for: B2B SaaS companies that need to add enterprise SSO without building it themselves.

WorkOS is purpose-built for the “we need to add SSO to our SaaS” use case. It gives you a single API and dashboard that handles SAML, OIDC, SCIM, and directory sync for every major IdP. Your integration is with WorkOS — they handle the per-customer IdP complexity.

Pricing (2026): The SSO product starts at $149/month for the first connection, with per-connection pricing at around $49–99/month after that. At 10 enterprise customers using SSO, expect $600–1,100/month. SCIM is included in the enterprise tier. No per-MAU pricing — this is a meaningful advantage over Auth0 at scale.

Limitation: You are coupling to WorkOS. Their API is not a standard. If you need to migrate off, it requires rearchitecting your auth flow.

Custom SAML/OIDC

When it makes sense:

• You have a compliance requirement (FedRAMP, IL4, on-premise deployment) that vendors cannot satisfy
• Your architecture needs session behavior that providers do not support (e.g., custom token introspection, specific cookie policies for regulated environments)
• You have outgrown provider pricing at 50K+ MAU
• You need to white-label the entire identity flow

What it costs: Building a production-grade SAML SP, OIDC RP, SCIM server, and session management system from scratch is a 6–10 week project for a senior engineer who knows the protocols. At €800–1,200/day consulting rates, that is €25,000–50,000 in development cost, plus ongoing maintenance as IdPs update their requirements.

The hidden cost: Protocol bugs in SAML validation are a security vulnerability, not just a compatibility issue. The XML signature verification step in particular has a history of being implemented incorrectly in ways that allow signature wrapping attacks.

Our recommendation: WorkOS for the large majority of B2B SaaS products moving upmarket. Auth0 if you need maximum protocol coverage and have the budget. Custom if you have a specific regulatory or architectural reason that providers genuinely cannot address.

For the full cost picture of custom SaaS development, see the custom SaaS development cost guide.

---

MFA Implementation

MFA at the enterprise tier goes beyond “users can turn it on.” IT admins need to be able to require it.

TOTP (RFC 6238)

The most widely deployed MFA factor. Shared secret (160-bit, base32-encoded) is stored server-side at enrollment. The TOTP algorithm: HOTP(secret, floor(unix_timestamp / 30)) produces a 6-digit code. Validate the current window and one window either side (to account for clock drift).

Store secrets encrypted at rest. If your user table is compromised, plaintext TOTP secrets are equivalent to access to every account.

Enrollment: generate the secret, show a QR code encoding otpauth://totp/{issuer}:{email}?secret={base32_secret}&issuer={issuer}, let the user verify with their first code before committing the enrollment.

WebAuthn / FIDO2

Hardware security keys (YubiKey, etc.) and platform authenticators (Face ID, Windows Hello) via the WebAuthn API. The strongest phishing-resistant MFA available.

The enrollment flow creates a public/private keypair on the authenticator. Your server stores the public key and a credential ID. At authentication, the authenticator signs a challenge with the private key, which your server verifies. The private key never leaves the hardware.

Implementation uses the browser’s navigator.credentials.create() and navigator.credentials.get() APIs. Libraries like SimpleWebAuthn (Node.js) handle the server-side verification correctly.

For enterprise customers, WebAuthn/FIDO2 is increasingly preferred over TOTP because it is phishing-resistant — a TOTP code can be intercepted by a real-time phishing proxy, a WebAuthn signature cannot.

Backup Codes

Always implement backup codes alongside any MFA method. Generate 8–10 single-use codes at enrollment, display them once, store them as bcrypt hashes. Users print them or store them in a password manager. Without backup codes, a user who loses their authenticator device is locked out permanently.

---

Session Management at Enterprise Scale

Session management is where most SaaS products have technical debt that becomes a security issue at enterprise scale.

Token Architecture

Use short-lived access tokens (15–60 minutes) paired with longer-lived refresh tokens (7–30 days). The access token is sent with every request — keeping it short-lived limits the window if it is compromised. The refresh token is exchanged for a new access token and is rotated on every use (refresh token rotation).

Store refresh tokens in HttpOnly, Secure, SameSite=Strict cookies. Do not store them in localStorage — XSS vulnerabilities can exfiltrate them. Access tokens can live in memory (a JavaScript variable) for the duration of the page session.

Session Revocation

When a user changes their password, all existing sessions should be invalidated. Implementation options:

• Token family tracking — store a family_id with each refresh token. On compromise detection (a refresh token used that has already been rotated), invalidate the entire family.
• Version field — add a session_version field to the user record. Increment it on password change or forced logout. Validate this version when refreshing tokens.
• Redis session store — for fine-grained control, store session metadata in Redis with a TTL. To revoke a session, delete the key.

Device Management

Enterprise customers increasingly want to see and revoke individual sessions. Build a “Sessions” page in the user’s account settings that shows: device type (user agent parsing), approximate location (IP geolocation), last active timestamp, and a “Sign out this device” action.

---

The SSO Tax Controversy

Many SaaS products historically put SSO behind a “Enterprise” pricing tier — sometimes 2–5x the base price. This practice is known as the “SSO tax” and it is legitimately controversial.

The argument for it: SSO implementation requires significant engineering investment and is disproportionately used by large customers who generate more support load and require compliance work.

The argument against it: SSO is a security feature. Putting it behind a paywall means smaller companies who cannot afford the Enterprise tier use your product with weaker security. It also generates significant negative press — see the sso.tax website which publicly catalogues egregious SSO pricing.

What to do instead:

Include SSO at a per-seat price threshold rather than a plan gate. If a customer has 25+ seats, SSO is included. This aligns the pricing with the actual cost (more seats = more enterprise complexity) without making security a feature that only rich customers can afford.

Alternatively: include OIDC-based SSO at your Growth tier (it is less complex to implement and maintain than SAML), and reserve SAML + SCIM for the Enterprise tier where you are doing custom IdP configuration work anyway.

---

Cost Breakdown at Different Scales

Scale	WorkOS	Auth0	Custom
5 enterprise customers	~$400/month	~$800/month	€35K upfront + maintenance
20 enterprise customers	~$1,100/month	~$1,500/month	€35K upfront + maintenance
50 enterprise customers	~$2,500/month	~$2,500/month	Break-even zone
100+ enterprise customers	~$5,000/month	~$4,000/month	Custom often wins

These are rough estimates — actual pricing depends on your contract negotiation, feature requirements, and whether SCIM is included in your tier. Always get a custom quote for significant scale.

For most SaaS products with fewer than 50 enterprise customers, WorkOS or Auth0 is meaningfully cheaper than building custom when you factor in engineering time, maintenance, and protocol updates.

---

What Enterprise Security Questionnaires Ask

When a 500-person company is evaluating your product, their IT or security team will send you a questionnaire. Expect these authentication-specific questions:

Access control:

• Does the application support SAML 2.0 SSO?
• Does the application support OIDC?
• Can our identity provider enforce MFA policies on your application?
• What MFA methods do you support (TOTP, hardware keys, push notifications)?
• Do you support SCIM for automated provisioning?

Session security:

• What is the session timeout for inactive users?
• Can administrators configure session timeout policies?
• Are sessions invalidated on password change?
• Do you support concurrent session limits?

Audit and compliance:

• Are authentication events logged (login success, failure, logout)?
• How long are authentication logs retained?
• Are logs available for export or SIEM integration?
• Is your authentication provider SOC 2 Type II certified?

Data and tokens:

• Where are authentication tokens stored?
• Are credentials encrypted at rest and in transit?
• Do you use your own identity service or a third-party provider? (If third-party, they will ask for the provider’s SOC 2 report.)

Using WorkOS or Auth0 makes most of these easy to answer: both have SOC 2 Type II certifications and publish compliance documentation that you can reference directly. Custom implementations require you to produce your own answers and evidence.

For a broader look at security best practices across a SaaS product, see the SaaS security best practices guide.

---

Implementation Timeline: What to Build When

MVP Phase (Month 1–3)

• Email/password authentication with bcrypt (cost: Argon2id is preferred — use argon2 library, not bcrypt, for new implementations)
• Google OAuth2 social login
• Email verification
• Password reset via signed tokens
• HttpOnly session cookies with a 24-hour expiry
• Basic rate limiting on authentication endpoints

Use Clerk or Auth0 free tier to avoid building this yourself. The engineering investment here is not differentiated — focus on your product.

Growth Phase (Month 4–12)

• TOTP-based MFA with backup codes
• Magic link login
• Session management UI (active sessions, revocation)
• Audit logging of authentication events
• Admin-level user management (invite, remove, role assignment)

Start thinking about your enterprise auth strategy here. Choose a provider that has SSO as an upgrade path.

Enterprise Phase (Month 12+, triggered by first enterprise deal)

• SAML 2.0 SP (via WorkOS or Auth0)
• OIDC RP
• SCIM server for automated provisioning
• Admin-enforced MFA policy
• Directory sync (group membership → role mapping)
• Per-organization SSO configuration UI
• WebAuthn/FIDO2 hardware key support

Do not build enterprise auth speculatively. Build it when the deal is real, not to impress prospects. The exception: if your go-to-market is exclusively enterprise from day one, build it in the Growth phase or use WorkOS from the start.

---

Choosing Your Path

The decision tree is simpler than most founders make it:

Are you in MVP stage? Use Clerk. Ship your product.

Do you have your first enterprise SSO deal? Add WorkOS. Configure the connection, close the deal.

Are you paying WorkOS more than €2,500/month? Evaluate whether custom implementation makes sense given your engineering team’s capacity and your roadmap.

Do you have a specific compliance requirement (FedRAMP, on-premise)? Custom from the start, built by engineers who have done it before.

The mistake we see most often: teams trying to build custom SAML in-house to “save money” at the 5-enterprise-customer stage. The math never works. At that scale, the engineering cost of building and maintaining the implementation dwarfs the WorkOS bill by a factor of 5–10.

The second most common mistake: teams that architect around a free tier of Auth0 and discover that SAML is an Enterprise feature only when the first real deal arrives, requiring a rushed upgrade negotiation.

---

Working With Us

If you are building a SaaS product that needs to sell to enterprise customers, authentication architecture is a decision you want to get right early. The cost of rearchitecting auth at the 50-customer mark is significantly higher than building it correctly at the 5-customer mark.

At Zulbera, we design and build enterprise-grade SaaS platforms — including full authentication stacks with SAML, OIDC, SCIM, MFA, and session management. We have implemented WorkOS integrations, custom SAML providers, and WebAuthn flows in production SaaS products.

If you are evaluating your authentication architecture or planning an enterprise move upmarket, contact us about custom SaaS development to talk through the options.

---

Further reading:

• SaaS Platform Architecture Decisions — how authentication fits into the broader technical stack
• SaaS Security Best Practices — security controls beyond authentication
• Custom SaaS Development Cost Guide — what enterprise SaaS actually costs to build