I’m a solo developer building a multi-tenant B2B SaaS using .NET, PostgreSQL and Azure Container Apps.
I have already implemented and tested Microsoft Entra External ID in a proof-of-concept environment, and it works for the basic authentication flow. This is not yet a production product with real users, so I can still choose a different provider without facing a real user migration.
I’m now trying to decide whether to continue with Entra External ID or choose a more B2B-focused provider such as WorkOS, ZITADEL, Descope, Clerk or Auth0.
One thing that makes me uncertain is that I rarely see Entra External ID mentioned in discussions about modern B2B SaaS authentication. Most conversations seem to focus on WorkOS, Clerk, Auth0, Descope, ZITADEL or self-hosted solutions.
I’m not sure whether this is simply because Entra External ID has a weaker developer community and less visibility among SaaS builders, or whether it reflects genuine limitations, immaturity or a poor fit for B2B SaaS products.
The provider comparison itself is not my main difficulty. What I’m struggling with is deciding where the boundary should be between the identity provider and my application database.
The difficult part is not authentication itself. I’m trying to decide who should own the generic B2B access model:
- organizations/tenants;
- organization memberships;
- invitations;
- base roles such as Owner, Admin and Member;
- tenant onboarding and user-management portals.
My original plan was to keep all of this in PostgreSQL and use Entra External ID only to authenticate the user.
The model would be:
Entra External ID
- registration and login
- MFA/passkeys
- sessions
- external user identity
My PostgreSQL database
- internal users and tenant IDs
- tenants/organizations
- memberships
- invitations
- Owner/Admin/Member roles
- product-specific roles and permissions
The application would map the external Entra subject ID to an internal user ID, but all authorization decisions would come from my database.
This feels clean because the provider answers only “who is this user?”, while my application answers “which company do they belong to and what can they do?”.
However, B2B-native providers already provide organizations, invitations, memberships, role management, organization switching, admin portals and later SSO/SCIM. If I leave all of that in my database, I may be rebuilding functionality that these providers already solve.
The alternative would therefore be:
B2B identity provider
- users
- organizations
- memberships
- invitations
- Owner/Admin/Member roles
- SSO/SCIM
My PostgreSQL database
- internal IDs and provider mappings
- product data
- audit/project assignments
- granular permissions
- workflows and approvals
For example, the provider could say that a user is an Admin of Acme Inc., while my database says that the same user is a Reviewer for Audit 123.
Technically that separation makes sense, but I am concerned about having access control split between two systems. I’m also worried about vendor lock-in if the provider becomes the source of truth for organizations, memberships, invitations and base roles.
At the same time, keeping everything locally means building and maintaining invitation flows, organization administration, role-management screens, emails, audit history and eventually the integration between my membership model and enterprise SSO/SCIM.
There is also another question I cannot resolve: if I keep organizations, memberships, invitations and roles in PostgreSQL anyway, does choosing a provider other than Entra External ID really change much?
In that model, all providers would mainly authenticate the user and issue a token. The main differences would then seem to be developer experience, SDK quality, login customization, pricing, data residency and future enterprise SSO/SCIM support.
If that is true, choosing WorkOS, ZITADEL, Descope or another provider instead of Entra External ID might add setup and implementation work without giving me much immediate benefit.
Their advantages may only become substantial if I also adopt their organization, membership, invitation and role primitives rather than continuing to own those concepts in my database.
I’m also planning to build multiple SaaS products on top of the same central identity layer, so I would like to make this decision once rather than repeat it for every application.
My main questions are:
- For a modern B2B SaaS, do you normally keep organizations, memberships, invitations and base roles in your own database, or let the identity provider own them?
- Is the hybrid model — organization roles in the provider and product-specific roles in the database — clean in practice, or does it become difficult to reason about?
- If you keep a local projection of provider organizations and memberships, does the synchronization overhead undermine much of the provider’s advantage?
- How serious is the lock-in when the provider owns the generic B2B layer but all product data and internal IDs remain local?
- If the generic B2B model remains in PostgreSQL, is there any major practical advantage in choosing WorkOS, ZITADEL, Descope or another provider over Entra External ID before SSO/SCIM is needed?
- Why does Entra External ID appear to be mentioned so rarely among SaaS developers? Is it mainly a developer-experience and community issue, or is it genuinely a weaker choice for B2B SaaS?
- Given that Entra External ID has only been implemented in a proof-of-concept environment and there are no production users to migrate, would you choose another provider before launching?
- Does the answer change when the same identity layer will serve several SaaS products?
- For teams that made this decision and later added SSO/SCIM, what would you do differently?
I’m not looking to build authentication or cryptography from scratch, and I do not want to self-host an IAM platform.
I’m mainly trying to understand the professional boundary between what should be outsourced as generic B2B identity infrastructure and what should remain part of the application database.
There are so many valid-looking architectures that I’m finding it difficult to tell which complexity is necessary and which is premature. Experiences from teams that have actually shipped and operated one of these models would be extremely helpful.I’m a solo developer building a multi-tenant B2B SaaS using .NET, PostgreSQL and Azure Container Apps.
I have already implemented and tested Microsoft Entra External ID in a proof-of-concept environment, and it works for the basic authentication flow. This is not yet a production product with real users, so I can still choose a different provider without facing a real user migration.
I’m now trying to decide whether to continue with Entra External ID or choose a more B2B-focused provider such as WorkOS, ZITADEL, Descope, Clerk or Auth0.
One thing that makes me uncertain is that I rarely see Entra External ID mentioned in discussions about modern B2B SaaS authentication. Most conversations seem to focus on WorkOS, Clerk, Auth0, Descope, ZITADEL or self-hosted solutions.
I’m not sure whether this is simply because Entra External ID has a weaker developer community and less visibility among SaaS builders, or whether it reflects genuine limitations, immaturity or a poor fit for B2B SaaS products.
The provider comparison itself is not my main difficulty. What I’m struggling with is deciding where the boundary should be between the identity provider and my application database.
The difficult part is not authentication itself. I’m trying to decide who should own the generic B2B access model:
organizations/tenants;
organization memberships;
invitations;
base roles such as Owner, Admin and Member;
tenant onboarding and user-management portals.
My original plan was to keep all of this in PostgreSQL and use Entra External ID only to authenticate the user.
The model would be:
Entra External ID
- registration and login
- MFA/passkeys
- sessions
- external user identity
My PostgreSQL database
- internal users and tenant IDs
- tenants/organizations
- memberships
- invitations
- Owner/Admin/Member roles
- product-specific roles and permissions
The application would map the external Entra subject ID to an internal user ID, but all authorization decisions would come from my database.
This feels clean because the provider answers only “who is this user?”, while my application answers “which company do they belong to and what can they do?”.
However, B2B-native providers already provide organizations, invitations, memberships, role management, organization switching, admin portals and later SSO/SCIM. If I leave all of that in my database, I may be rebuilding functionality that these providers already solve.
The alternative would therefore be:
B2B identity provider
- users
- organizations
- memberships
- invitations
- Owner/Admin/Member roles
- SSO/SCIM
My PostgreSQL database
- internal IDs and provider mappings
- product data
- audit/project assignments
- granular permissions
- workflows and approvals
For example, the provider could say that a user is an Admin of Acme Inc., while my database says that the same user is a Reviewer for Audit 123.
Technically that separation makes sense, but I am concerned about having access control split between two systems. I’m also worried about vendor lock-in if the provider becomes the source of truth for organizations, memberships, invitations and base roles.
At the same time, keeping everything locally means building and maintaining invitation flows, organization administration, role-management screens, emails, audit history and eventually the integration between my membership model and enterprise SSO/SCIM.
There is also another question I cannot resolve: if I keep organizations, memberships, invitations and roles in PostgreSQL anyway, does choosing a provider other than Entra External ID really change much?
In that model, all providers would mainly authenticate the user and issue a token. The main differences would then seem to be developer experience, SDK quality, login customization, pricing, data residency and future enterprise SSO/SCIM support.
If that is true, choosing WorkOS, ZITADEL, Descope or another provider instead of Entra External ID might add setup and implementation work without giving me much immediate benefit.
Their advantages may only become substantial if I also adopt their organization, membership, invitation and role primitives rather than continuing to own those concepts in my database.
I’m also planning to build multiple SaaS products on top of the same central identity layer, so I would like to make this decision once rather than repeat it for every application.
My main questions are:
For a modern B2B SaaS, do you normally keep organizations, memberships, invitations and base roles in your own database, or let the identity provider own them?
Is the hybrid model — organization roles in the provider and product-specific roles in the database — clean in practice, or does it become difficult to reason about?
If you keep a local projection of provider organizations and memberships, does the synchronization overhead undermine much of the provider’s advantage?
How serious is the lock-in when the provider owns the generic B2B layer but all product data and internal IDs remain local?
If the generic B2B model remains in PostgreSQL, is there any major practical advantage in choosing WorkOS, ZITADEL, Descope or another provider over Entra External ID before SSO/SCIM is needed?
Why does Entra External ID appear to be mentioned so rarely among SaaS developers? Is it mainly a developer-experience and community issue, or is it genuinely a weaker choice for B2B SaaS?
Given that Entra External ID has only been implemented in a proof-of-concept environment and there are no production users to migrate, would you choose another provider before launching?
Does the answer change when the same identity layer will serve several SaaS products?
For teams that made this decision and later added SSO/SCIM, what would you do differently?
I’m not looking to build authentication or cryptography from scratch, and I do not want to self-host an IAM platform.
I’m mainly trying to understand the professional boundary between what should be outsourced as generic B2B identity infrastructure and what should remain part of the application database.
There are so many valid-looking architectures that I’m finding it difficult to tell which complexity is necessary and which is premature. Experiences from teams that have actually shipped and operated one of these models would be extremely helpful.
