How do I build SSO into a new SaaS app?

Building SSO into a new SaaS app usually means supporting one or more enterprise identity protocols so customers can log in with their company IdP instead of creating separate app passwords.

1) Decide what kind of SSO you need

For most SaaS products, the common options are:

• SAML 2.0: Very common for enterprise SSO, especially with Okta, Azure AD, Ping, ADFS.
• OpenID Connect (OIDC) / OAuth 2.0: Modern, simpler to implement, great for new apps and many identity providers.
• Both: Best if you want broad enterprise compatibility.

If you’re starting fresh, I’d usually recommend:

• OIDC for your own auth architecture
• SAML for enterprise customer compatibility

2) Choose your auth model

A typical SaaS pattern is:

• Your app has its own user accounts
• Each tenant/org can configure one or more IdPs
• Users sign in via:
  • email domain discovery, or
  • a “Sign in with SSO” button, or
  • a tenant-specific login URL

You’ll need to support:

• Tenant-level SSO settings
• IdP connection config
• User provisioning / linking
• Role mapping
• Logout handling if needed

3) Use a proven identity provider / library

You can build this yourself, but it’s often easier to use a managed auth platform.

Managed options

• Auth0
• WorkOS
• Clerk
• Stytch
• Firebase Auth (less enterprise SSO-focused)
• AWS Cognito (possible, but enterprise SSO UX can be clunky)

If enterprise customers are important, WorkOS + your app is a common SaaS approach because it handles SAML/OIDC integration and directory sync cleanly.

If building yourself

Use battle-tested libraries:

• Node.js: passport-saml, openid-client, passport-openidconnect
• Python: python3-saml, Authlib
• Ruby: omniauth-saml, openid_connect
• Java: Spring Security SAML/OIDC
• .NET: Microsoft.Identity.Web, Sustainsys.Saml2

4) Core SSO flow you need

For SAML

1. User enters email or tenant URL
2. You identify the tenant
3. Redirect to IdP with SAML AuthnRequest
4. IdP authenticates user
5. IdP posts SAML Response to your ACS endpoint
6. You validate signature, audience, issuer, timestamps
7. Map the asserted identity to a user in your system
8. Create a session for the app

For OIDC

1. User clicks “Sign in with SSO”
2. Redirect to IdP authorize endpoint
3. IdP authenticates user
4. IdP redirects back with code
5. Your backend exchanges code for tokens
6. Validate ID token, issuer, audience, nonce
7. Map to user and create session

5) Design your user/account linking

Important decision: how do you identify a user?

Common keys:

• email
• email + tenant
• IdP subject / NameID
• external identity record

Best practice:

• Store a separate Identity table linking:
  • tenant_id
  • provider_type (saml, oidc)
  • provider_id
  • subject / nameid
  • user_id
• Don’t rely only on email long-term; emails can change.

6) Support Just-in-Time provisioning

When a new user logs in via SSO:

• If no matching account exists, create one automatically
• Optionally assign default role
• Optionally require admin approval for first login

Also consider:

• If user already exists by email, link the SSO identity to that account after verification
• Prevent account hijacking by requiring admin-initiated linking or domain verification

7) Add SCIM if you want enterprise-grade provisioning

SSO lets users log in. SCIM lets the customer provision/deprovision users automatically.

With SCIM, the IdP can:

• create users
• deactivate users
• sync groups/roles

If your SaaS is enterprise-focused, SCIM is often expected alongside SSO.

8) Plan tenant configuration UX

You’ll need admin pages for:

• enabling SSO per tenant
• choosing provider type
• uploading metadata or entering OIDC details
• configuring:
  • SAML entity ID, ACS URL, certificate, IdP metadata
  • OIDC issuer, client ID, client secret, redirect URI
• testing connection
• enforcing SSO for the org
• fallback/admin login path

9) Be careful with security

Security basics:

• Validate all protocol fields strictly
• Enforce signature verification for SAML assertions/responses
• Validate audience, issuer, timestamps, nonce/state
• Use HTTPS everywhere
• Protect against replay attacks
• Store secrets/certs securely
• Rotate signing certs and client secrets
• Keep an emergency non-SSO admin access path

Common mistakes:

• trusting email alone
• not validating SAML signatures properly
• not checking audience / recipient / inResponseTo
• linking identities without verifying domain ownership
• breaking access when a customer misconfigures SSO

10) Decide login experience and fallback

Good SaaS login UX often includes:

• Email entry first
• Detect company domain and route to IdP
• “Continue with SSO”
• “Forgot password” only for non-SSO accounts
• Emergency local admin login or break-glass account

You should also handle:

• IdP unavailable
• invalid config
• expired certificates
• user not assigned in IdP
• multiple IdPs for one tenant

11) Recommended architecture

A practical SaaS auth setup:

• App session layer: your app issues its own session cookies/JWTs
• Auth broker layer: handles SAML/OIDC with IdPs
• User directory: tenants, users, identities, roles
• Provisioning layer: optional SCIM
• Audit logs: login events, admin changes, failed assertions, provisioning actions

12) Minimal implementation path

If you want the fastest path to production:

1. Build normal email/password login first
2. Add OIDC SSO for a small set of providers
3. Add SAML for enterprise compatibility
4. Add tenant-level SSO config UI
5. Add JIT provisioning and account linking
6. Add SCIM
7. Add audit logging and admin controls

13) If you want to outsource it

If your goal is to ship quickly and avoid protocol complexity, use:

• WorkOS for SSO + SCIM
• Auth0 for broader auth platform needs
• Clerk/Stytch if they fit your product and pricing

That’s often the best choice for a new SaaS unless auth is a core differentiator.

If you want, I can also give you:

1. a recommended SSO architecture diagram,
2. a database schema for SSO tenants/users/identities, or
3. a step-by-step implementation example in your stack (Node, Python, Ruby, .NET, etc.).