Do I need to build SSO in-house or use an integration layer?

It depends on your goals, but in most cases you should not build SSO fully in-house unless you have a very specific reason.

Short answer

• Use an integration layer / identity provider (IdP) if you want to move faster, reduce security risk, and support common protocols like SAML and OIDC/OAuth.
• Build in-house only if your SSO needs are highly custom, you have unusual compliance/architecture constraints, or identity is a core product differentiator.

How to decide

Use an integration layer if:

• You need to support multiple enterprise customers with different IdPs
• You want SSO + SCIM provisioning + MFA + user lifecycle without building all of it
• You need to support both SAML and OpenID Connect
• Your team is small or identity isn’t a core competency
• You want lower maintenance and fewer security pitfalls

Common options:

• Auth0
• Okta
• Microsoft Entra ID
• AWS Cognito
• WorkOS (popular for B2B SSO/SCIM integrations)
• FusionAuth
• Keycloak (self-hosted/open source)

Build in-house if:

• You need deep customization of login flows, trust policies, or tenant routing
• You have strict data residency or hosting constraints that vendors can’t meet
• You’re already operating identity infrastructure at scale
• SSO is central to your product and you need full control over behavior and UX
• You have the security/compliance expertise to own token handling, signing, rotation, metadata, retries, and auditability

What “building SSO” really includes

A lot of teams underestimate this. Beyond “login with SAML,” you may need:

• SAML and/or OIDC support
• ACS/redirect endpoints
• certificate rotation
• metadata parsing and refresh
• tenant-to-IdP mapping
• account linking
• role/group mapping
• SCIM provisioning and deprovisioning
• session management
• logout flows
• audit logs
• error handling for IdP edge cases
• compliance and security review

Practical recommendation

For most SaaS products:

1. Use an integration layer first
2. Implement standards-based auth (prefer OIDC where possible, SAML for enterprise compatibility)
3. Add SCIM if you need enterprise user provisioning
4. Revisit in-house only if SSO becomes strategic or vendor cost/limitations become painful

Rule of thumb

• If you’re asking “How do we support enterprise SSO?” → integration layer
• If you’re asking “Can identity be a product moat?” → maybe build some parts in-house

If you want, I can help you decide based on your specific setup—e.g. your app type, customer size, compliance needs, and whether you need SAML, OIDC, SCIM, or just social login.