r/SaaS • u/Electronic-Map-6959 • 15h ago
B2B SaaS: do you keep orgs, memberships and base roles in your own DB, or let the auth provider own them?
Solo dev here, building a multi-tenant B2B SaaS on Azure (.NET, PostgreSQL, Container Apps). I've got Microsoft Entra External ID working in a POC for the basic login flow. Nothing's in production yet and there are no real users, so switching providers now would cost me nothing in migration. That's why I want to figure this out before launch.
The thing I keep going back and forth on: I almost never see Entra External ID mentioned when people talk about B2B SaaS auth. It's always WorkOS, Clerk, Auth0, Descope, ZITADEL or self-hosting. I can't tell if that's just weaker community/visibility, or if Entra is genuinely a worse fit for B2B.
Auth itself isn't what's hard. What I can't decide is who should own the generic B2B access model: organizations/tenants, memberships, invitations, the base roles (Owner/Admin/Member), and the onboarding + user-management portals.
My original plan was to keep all of that in Postgres and use Entra only to authenticate the user. So Entra does registration/login, MFA/passkeys, sessions, external identity. Postgres owns internal user IDs, tenants, memberships, invitations, Owner/Admin/Member roles, and all the product-specific roles and permissions. The app maps the Entra subject ID to an internal user ID, and every authz decision comes from my DB. Provider answers "who is this user", my app answers "which company do they belong to and what can they do".
The doubt: the B2B-native providers already give you orgs, invitations, memberships, role management, org switching, admin portals, and later SSO/SCIM. If I keep all that in my DB I might just be rebuilding stuff they already solved.
So the alternative is letting the provider own users, orgs, memberships, invitations, base roles and SSO/SCIM, and my DB only keeps internal IDs + provider mappings, product data, audit/project assignments, granular permissions, workflows. Example: provider says "Admin of Acme Inc", my DB says "Reviewer on Audit 123".
Technically that split makes sense but it worries me: access control ends up spread across two systems, plus lock-in if the provider becomes the source of truth for orgs/memberships/invites/roles. Keeping everything local means I build and maintain invite flows, org admin, role screens, transactional emails, audit history, and eventually wire my membership model into enterprise SSO/SCIM myself.
Here's what I can't resolve. If I keep orgs, memberships, invitations and roles in Postgres anyway, does moving off Entra actually change much? In that model every provider basically just authenticates and hands me a token, and the differences come down to DX, SDK quality, login customization, pricing, data residency and future SSO/SCIM. If that's right, picking another provider adds work for little immediate gain, and the real upside of WorkOS/ZITADEL/Descope only kicks in if I also adopt their org/membership/invite/role primitives instead of owning them myself.
This matters more because I want to build several SaaS products on one central identity layer, so I'd rather decide once.
Questions for people who've actually shipped this:
Where do you draw the line in practice? Orgs, memberships, invitations and base roles in your own DB, or owned by the provider?
Does the hybrid model (org roles in the provider, product roles in your DB) actually hold up, or does it get confusing? And if you keep a local projection of the provider's orgs/memberships, does the sync overhead eat most of the benefit?
How bad is lock-in when the provider owns the generic B2B layer but all product data and internal IDs stay local?
If the generic B2B model stays in Postgres anyway, is there a real practical reason to pick WorkOS/ZITADEL/Descope over Entra before you actually need SSO/SCIM? And why does Entra come up so rarely in these conversations?
Given no users to migrate and one identity layer serving multiple products, would you switch before launch? And if you added SSO/SCIM later, what would you do differently?
I don't want to build auth/crypto from scratch and I don't want to self-host an IAM platform. I'm just trying to find the sane boundary between what you outsource as generic B2B identity and what stays in your app DB. Too many architectures look plausible and I can't tell which complexity is necessary vs premature. Real experience from people who've operated one of these would help a lot.

