The first time a sales conversation turns into “we need SSO by next quarter,” you have two options: ship the integration in 2 weeks, or ship it in 3 months. The difference is entirely architectural choices you made a year earlier, when you didn’t know you’d need SSO.
Four things to do now.
1. Tenant-aware user model from day one
Even if you have one tenant today, build the plumbing:
- A
tenantstable - Every membership has a role within a tenant
- Every query is tenant-scoped
When you add SSO, each tenant configures its own IdP. The tenant-aware model is what makes this possible. Retrofitting tenancy after the fact is the biggest time sink in most “add SSO” projects.
2. Auth provider flag on the user
Add an auth_provider column (or similar) on your users or memberships table. Values like local, google, microsoft, saml:tenant-123, scim:tenant-123.
Why: when SSO is added, a user may sign in via their employer’s IdP. The sign-in path should be unified — look up the user, check their provider, route to the right flow. If you bake “local only” assumptions into your code (a password column on every user, for example), SSO users will either have fake passwords or your code paths will diverge.
3. Treat email as non-unique
Classic bug: a user signs up with jane@acme.com using Google. Later, ACME buys your product and enables SAML. SAML login for jane@acme.com creates a new user, because your code assumes email uniqueness. Now Jane has two accounts.
The fix: treat email as a property, not an identifier. The identifier is (tenant_id, auth_provider, subject). Email is metadata. Collisions across auth providers are expected.
Ship this from day one and the SAML integration is a non-event. Retrofit this and you’re migrating production data while customers are using it.
4. Don’t let SSO users change their own email
If a user signs in via SAML with jane@acme.com, they shouldn’t be able to change that email to jane-personal@gmail.com in your settings. Why? Because the SAML IdP is the source of truth for that user’s identity. A user-driven email change creates inconsistency that becomes a support nightmare at best and an account takeover vector at worst.
Rule: if auth_provider != 'local', the email is read-only. Changes must come from the IdP (via SAML attribute changes or SCIM updates).
What to defer
Don’t ship SAML or SCIM before a customer asks. It’s tempting — “we’ll be enterprise-ready!” — but the implementation is non-trivial, and every IdP has quirks you can only debug against a real customer. Architect for it; don’t build it preemptively.
When the first customer asks, you have two weeks of integration work, not two quarters. That’s the entire payoff.
Timeline
- Day 1: tenant-aware schema
- Week 1:
auth_providercolumn - Month 1: email-as-metadata semantics
- Month 6: first enterprise prospect asks
- Month 6.5: SSO is live
That’s the plan. Do the day-one work and everything else falls into place.