I'm a solo developer building a multi-tenant B2B SaaS on Azure with .NET, PostgreSQL, and Container Apps. For now, I don't need enterprise SSO, SAML, or SCIM, although I may add those later.
I plan to keep tenancy and authorization in my own database. PostgreSQL will remain the source of truth for organizations, memberships, roles, invitations, and tenant onboarding, while the identity provider mainly issues tokens and handles authentication.
Most comparisons between Entra External ID and services such as WorkOS, Zitadel, or Clerk focus on enterprise SSO and provisioning. For the simpler B2B case, does External ID provide enough functionality, or do the dedicated providers offer useful organization and invitation features that External ID lacks?
My concern is that if I own the organization and membership model in my database anyway, a provider's built-in organization abstraction could become a second source of truth that needs synchronization. In that situation, does a dedicated provider still offer a meaningful advantage when SSO and SCIM are not required, or does most of its value disappear?
I'm also considering using the same authentication layer for several SaaS products. Would that make a dedicated provider more attractive? External ID has felt somewhat mechanical and clunky so far, though that's only an initial impression. I'm interested in the experience of people who have actually shipped products with it.
1 Answer
If your application database is deliberately the source of truth for organizations, roles, memberships, and authorization, then a provider's built-in organization model usually isn't a major advantage by itself. You would still need to mirror users and membership changes into PostgreSQL and make sure your application handles invitations, onboarding, and authorization consistently.
The main benefit of a dedicated provider in the basic case is speed: it may give you polished invitation flows, user-management screens, organization switching, lifecycle events, and APIs so you write less product code. But if you intend to build those flows around your own data anyway, that advantage becomes much smaller. External ID can be a reasonable choice when you mainly need authentication and token issuance, especially if staying within Azure matters.
A shared auth layer for multiple products could make a provider with better cross-application UX, APIs, webhooks, and account-management tooling worthwhile. Otherwise, it may be simpler to keep identity in External ID and build a reusable internal tenant and membership service on top of your database. Reassess when SSO, SCIM, delegated administration, audit requirements, or more polished onboarding become immediate needs.
That matches my concern. Since the application has to maintain its own membership and authorization records either way, the dedicated provider's organization features seem more like a convenience layer than a fundamental capability. The decision probably comes down to how much time I want to spend building and maintaining the surrounding management UX, plus whether the multi-product setup makes centralized tooling more valuable later.