SSO: Customer Entra ID as IdP for Entra External Id with self-sign-up user configuration

Based on the documented capabilities, the described scenario is supported in principle, but only in specific ways and with important constraints.

Key points from the platform behavior:

1. External ID supports Entra ID as an identity provider
   • External ID (CIAM) supports Microsoft Entra accounts and Microsoft Entra ID federation as identity providers, alongside social IdPs and custom OIDC providers.
   • In an external tenant (TenantB), sign-in methods can include “Microsoft Entra ID” as an IdP, and customers can use their Entra accounts to sign in via federation.
   • Identity providers are configured at the tenant level and then enabled in the self-service sign-up user flow.
2. Self-service sign-up user flows are the supported way to onboard external users
   • For CIAM scenarios, self-service sign-up user flows in the external tenant are the supported mechanism to let customers register themselves for the app.
   • These user flows can:
     • Offer multiple sign-in methods (email+password, one-time passcode, social IdPs, Entra ID federation, custom OIDC, etc.).
     • Collect business attributes (including custom attributes) such as an access/invitation code during sign-up.
     • Enforce that only users who complete the flow (and thus are created in TenantB) can sign in.
3. How SSO with a customer Entra tenant fits
   • External ID supports Microsoft Entra ID federation as an identity provider. This is the supported pattern for “Customer TenantA as IdP for TenantB” in CIAM:
     • TenantB (external tenant) is the CIAM directory for the app.
     • TenantA (customer workforce tenant) is configured as an Entra ID / enterprise IdP for TenantB.
     • Users from TenantA authenticate in their home tenant; TenantB issues tokens for the app.
   • This aligns with the documented model where External ID supports Microsoft Entra accounts and Entra ID federation as identity providers for self-service sign-up and sign-in.
4. Self-registration + business access code
   • External ID user flows allow collecting custom attributes during sign-up.
   • A business-defined access/invitation code can be implemented as a custom attribute collected in the sign-up flow.
   • Only users who successfully complete the sign-up flow (including providing a valid code if enforced in business logic) will be created in TenantB and can sign in.
   • Additional business logic (for example, validating the code against an external system and adding claims) can be implemented using custom authentication extensions.
5. “Only registered users can sign in”
   • In External ID, the external tenant (TenantB) holds the directory of customer accounts.
   • Self-service sign-up user flows create local accounts in TenantB.
   • Sign-in user flows can be configured so that only users who exist in TenantB (created via sign-up or pre-provisioned) can sign in.
6. B2B collaboration vs CIAM
   • The earlier guidance about Entra ID B2B collaboration (guest users in a workforce tenant) applies to workforce tenants and B2B collaboration scenarios.
   • For CIAM with an external tenant, the supported pattern is:
     • Use an external tenant dedicated to customer identities.
     • Use self-service sign-up user flows.
     • Configure Entra ID federation and other IdPs as needed.
   • External ID supports multiple identity providers, including Microsoft Entra accounts, Entra ID federation, social IdPs, and custom OIDC/SAML/WS-Fed, with behavior depending on tenant configuration and whether the user is invited or uses self-service sign-up.
7. About OIDC/SAML configuration issues
   • The documentation confirms that External ID supports custom OIDC and SAML/WS-Fed IdP federation in external tenants.
   • If OIDC or SAML federation from TenantA to TenantB is failing, this indicates a configuration issue rather than a platform limitation, provided the configuration follows the supported federation patterns (for example, registering TenantA as a Microsoft Entra ID or custom OIDC/SAML IdP in TenantB and enabling it in the user flow).

Summary for the described requirement:

• “If Customer TenantA – use IdP TenantA flow; else – use web user” is supported conceptually by:
  • Configuring TenantA as an Entra ID / enterprise IdP (or custom OIDC/SAML IdP) in TenantB.
  • Enabling both TenantA IdP and local accounts (email+password / one-time passcode) in the same self-service sign-up and sign-in user flow.
  • Using user flow attributes and/or custom authentication extensions to collect and validate the business access code.
• The platform supports Entra ID federation and custom OIDC/SAML IdPs in External ID; inability to get OIDC/SAML working between TenantA and TenantB indicates configuration problems, not a fundamental lack of support, as long as the setup follows the documented External ID federation patterns.

References:

• Overview: Secure your apps using External ID in an external tenant
• Self-service sign-up
• Create a sign-up and sign-in user flow for an external tenant app
• Identity providers for External ID in workforce tenants
• Microsoft Entra External ID frequently asked questions