Environment
- ABP Framework version: 10.2
- Feature: Shared User Accounts (
TenantUserSharingStrategy.Shared)
Description
The new Shared User Accounts feature introduces a "global authentication first, tenant selection after" model. While this is a great UX improvement for multi-tenant users, it creates a fundamental conflict with a very common B2B SaaS requirement: per-tenant external identity provider (IdP) configuration.
In enterprise B2B scenarios, each tenant (customer organization) typically brings their own Azure AD / Entra ID (or Okta, etc.) with their own ClientId, ClientSecret, and TenantId. This is standard practice — each organization controls their own identity infrastructure.
With the Shared strategy, authentication happens at the Host level before the tenant is known, which means the system cannot determine which tenant's IdP credentials to use for the OIDC challenge.
Scenarios that break
Scenario 1: Per-tenant Entra ID credentials
A SaaS platform serves multiple enterprise customers. Each customer has configured their own Azure AD application registration:
| Tenant | Entra ID ClientId | Entra ID TenantId |
| ------ | ----------------- | ----------------- |
| Acme Corp | aaa-111 | acme-tenant-id |
| Contoso | bbb-222 | contoso-tenant-id |
With the Isolated strategy, the tenant is resolved first (via subdomain, email domain, etc.), so the system knows which Entra ID credentials to use for the OIDC challenge.
With the Shared strategy, the user authenticates globally first — but against which Entra ID? The system doesn't know the target tenant yet.
Scenario 2: Mixed authentication methods across tenants
A user (john@example.com) belongs to two tenants:
- Tenant A: Requires Entra ID SSO (enterprise policy, no password login allowed)
- Tenant B: Uses standard username/password (small team, no IdP)
With Shared, authentication is global — so which method applies? If the Host enforces Entra ID, Tenant B users can't log in with passwords. If it allows passwords, Tenant A's enterprise SSO requirement is bypassed.
Scenario 3: Per-tenant security policies
The documentation states that security settings (2FA, lockout, password policies) are managed at the Host level with Shared strategy. In B2B SaaS, each tenant admin typically controls their own security policies:
- Tenant A (financial services): Mandatory 2FA, strict password policy, 3-attempt lockout
- Tenant B (startup): No 2FA, relaxed password policy
Centralizing these at Host level removes a key selling point for enterprise customers who need to enforce their own compliance requirements.
Why this matters
Per-tenant IdP configuration is not an edge case — it's a core requirement for B2B SaaS platforms:
- Enterprise customers expect SSO with their own IdP (Azure AD, Okta, Auth0, etc.)
- Compliance frameworks (SOC 2, ISO 27001, HIPAA) often require organizations to control their own authentication policies
- Zero Trust architectures mandate that each organization manages their own identity boundary
Proposed Solutions
Option A: Hybrid flow — Tenant selection before authentication
Allow a pre-authentication tenant selection step. The flow would be:
- User enters email → system resolves possible tenants (from membership)
- User selects tenant → system loads tenant's IdP configuration
- Authentication happens within the tenant's context (using tenant's Entra ID, security policies, etc.)
- Post-authentication, tenant switching is available (but re-authentication may be required when switching to a tenant with a different IdP)
This preserves the UX benefits of Shared (one account, multiple tenants) while supporting per-tenant IdP.
Option B: Per-tenant security policy overrides
Even if authentication is global, allow tenants to define security policy overrides that apply when a user is operating within that tenant's context (e.g., require 2FA to access Tenant A, but not Tenant B).
2 Answer(s)
-
0
- With
TenantUserSharingStrategy.Sharedin ABP 10.2, the login flow is host-first (global identity is established before a tenant context is selected). As a result, tenant-specific runtime OIDC challenge configuration (Authority/ClientId/ClientSecret per tenant) is not compatible with the Shared strategy’s core flow, because the system doesn’t know the tenant at the moment it must choose the external IdP to challenge. - In ABP, per-tenant external login configuration is supported when the tenant context is known (classic multi-tenancy flow). The Account.Pro “External Logins” system is explicitly described as multi-tenant compatible and allows each tenant to configure/override provider settings. However, that model assumes the tenant can be resolved before initiating the challenge.
- Therefore, for your scenarios:
- Per-tenant Entra ID credentials: cannot be deterministically selected at the start of authentication under Shared (tenant unknown).
- Mixed authentication methods across tenants: Shared makes authentication rules global-first; tenant-specific “must use SSO / must forbid password” cannot be enforced at the initial sign-in step in the standard Shared flow.
- Per-tenant security policies: in Shared, those are host-level by design (ABP documentation also states security settings are managed at Host level).
What you can do (verified ABP-supported approaches):
Use
TenantUserSharingStrategy.Isolatedif you require per-tenant IdP selection at sign-in- This is the only fully consistent approach if each tenant brings its own Entra/Okta config and the tenant must be resolved before challenge.
- You still can provide a good UX with tenant resolution (subdomain, tenant name, email domain mapping, etc.), but it won’t be “global-auth first”.
Keep Shared, but restrict yourself to “global external IdP(s)” (host-level)
- If you can use a single Entra multi-tenant app registration (or a single federation entry point) for all customers, Shared works well because the host can always challenge the same provider.
- Tenants can still differ in authorization/roles/permissions after tenant selection, but not in initial IdP selection.
If you need tenant-specific allowed login methods (not tenant-specific OIDC credentials), customize external provider availability per tenant
- ABP support guidance shows you can replace
ExternalProviderSettingsHelperto filter which external providers are available per tenant (e.g., TenantA sees “windows,google”, TenantB sees “google”). This can help with “mixed authentication methods across tenants” only after tenant context exists (e.g., on tenant-specific login pages or flows that resolve tenant early). - This is done by replacing the service (example shown in ABP support answer), and using
ICurrentTenantto decide which providers to return.
- ABP support guidance shows you can replace
Hybrid flow (tenant selection before authentication) is not provided as a built-in mode for Shared in ABP 10.2
- Your “Option A” (email → resolve tenants → select tenant → challenge correct IdP) is conceptually valid, but there is no verified built-in ABP 10.2 feature that changes Shared’s host-first external challenge to tenant-first selection.
- Implementing that would require a custom login UX + custom authentication flow, and you’d effectively be reintroducing “tenant known before auth” for external login—at which point
Isolatedis usually the simpler/cleaner solution.
Sources (validated)
- https://abp.io/docs/10.2/modules/account/shared-user-accounts
- https://abp.io/docs/latest/modules/account-pro
- https://abp.io/support/questions/6637
- https://abp.io/support/questions/8731
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
- With
-
0
Any ABP team insights?
