I'm building a SaaS dashboard and need to add SAML login without breaking password auth. Any advice?

Yes — the safest approach is to add SAML as an additional auth method, not a replacement, and design the account model so one user can have multiple login methods.

Recommended approach

1) Keep a single user record, add linked identities

Model auth like this:

• User: your internal account
• Credentials / Identities: linked login methods such as:
  • password
  • SAML IdP
  • Google/Microsoft OIDC later, if needed

Example:

• users
• user_passwords
• user_saml_identities

This lets the same user log in with either password or SAML.

---

2) Separate authentication from account ownership

Don’t make “SAML user” a different user type unless you really must.

Instead, once SAML succeeds:

• identify the user by a stable claim like:
  • NameID only if guaranteed stable
  • better: IdP issuer + subject/immutable user ID
• if there’s a match, log into the existing user
• if not, create/link a new identity

---

3) Support account linking carefully

Common flows:

Existing password user adds SAML

1. User signs in with password
2. User goes to “Connect SSO”
3. They complete SAML
4. You link the SAML identity to their user

New SAML login to existing email

If the SAML assertion email matches an existing account:

• don’t auto-link blindly unless you trust the IdP and domain
• ideally require one of:
  • existing user is already signed in
  • email verification
  • admin-approved linking
  • domain/tenant restrictions

This avoids account takeover.

---

4) Decide your “source of truth” for password auth

If a user has both methods:

• password login should continue to work unless disabled
• SAML can be optional per org, or required for some orgs

If an organization enables SSO enforcement:

• users in that org may be forced to use SAML
• but keep a break-glass admin account with password auth for recovery

---

5) Multi-tenant SaaS: tie SAML to org/workspace

Usually SAML is enabled per:

• organization
• workspace
• tenant

Then your login logic becomes:

1. determine tenant
2. if tenant uses SAML, offer SSO or redirect
3. otherwise allow password login
4. if user has both credentials, either can authenticate

Be careful with users belonging to multiple orgs with different auth policies.

---

Security gotchas to avoid

• Don’t trust email alone as the unique identifier
• Validate SAML signatures, audience, issuer, expiration
• Enforce clock skew limits
• Use signed assertions and/or responses properly
• Prevent relay state tampering
• Store and compare a stable IdP identifier + user identifier
• Protect against duplicate account creation when the same person signs in via two methods

---

UX recommendations

• On the login page, show:
  • “Sign in with password”
  • “Sign in with SSO”
• If you know the tenant from subdomain or email domain, you can prefill or route to SSO
• On account settings:
  • show linked sign-in methods
  • allow users to add/remove password if policy permits
• If SSO is required, explain it clearly and provide recovery steps

---

Practical database shape

A simple model:

• users(id, email, name, org_id, ...)
• auth_identities(id, user_id, provider, provider_issuer, provider_subject, created_at, last_login_at)
• password_credentials(user_id, password_hash, password_updated_at, enabled)

Unique constraint suggestion:

• (provider, provider_issuer, provider_subject) unique
• optionally unique on normalized email per org if that fits your product

---

Good rollout plan

1. Add identity table
2. Implement SAML login behind a feature flag
3. Allow linking from authenticated sessions
4. Test edge cases:
   • same email across different IdPs
   • user in multiple orgs
   • password + SAML coexistence
   • account recovery
5. Roll out per tenant

---

If you want, I can also sketch:

• a recommended schema
• the login/linking flow
• or sample implementation patterns for Node/Express, Django, Rails, or .NET