How to auto-provision users in an external tenant on first sign-in via a custom OIDC identity provider

Chintan Sukhadiya 0 Reputation points
2026-07-31T17:54:33.7966667+00:00

We run Microsoft Entra External ID external tenants with a custom OIDC identity provider (federating to a Microsoft Entra workforce tenant) attached to a sign-up and sign-in user flow. Local-account self-service sign-up is disabled by design.

Requirement: when a user from an allowed organization signs in for the first time and no user object exists yet in the external tenant, the user should be created automatically, no B2B invitation, no admin pre-creation, no Graph provisioning job.

Question: what is the supported way to achieve this? Specifically:

  1. Is federated first-sign-in auto-provisioning through the user flow the intended mechanism, and does disabling local-account sign-up affect it in any way?
  2. Under what conditions does it not create the user (e.g., when an object with the same email already exists as a B2B external user, or when a previously created object is soft-deleted)? What is the recommended handling for those cases?
  3. Is there any way to get the same auto-provisioning when the user types their email on the identifier-first page (rather than clicking the identity provider button)?
Microsoft Security | Microsoft Entra | Microsoft Entra External ID
0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-07-31T17:54:57.74+00:00

    The supported first-sign-in auto-provisioning path in an external tenant is the sign-up and sign-in user flow with the federated identity provider enabled in that user flow. When a user selects the federated Microsoft Entra ID identity provider on the sign-in page and successfully authenticates, a user account is automatically created in the external tenant.

    For the specific behavior when local sign-up is disabled:

    1. Intended mechanism
      • Yes. Sign-in-time creation through the user flow is the documented mechanism for federated users.
      • However, if sign-up is disabled, current behavior does not allow automatic creation of users from federated identity providers. In that configuration, setting isSignUpAllowed to false prevents both local sign-up and automatic creation of external users through the federated IdP.
      • So, the requirement as stated is not supported with sign-up disabled.
    2. When user creation does not occur
      • The context supports one explicit case: when sign-up is disabled, federated first sign-in does not create the user.
      • The context does not provide supported rules for other collision or lifecycle cases such as:
        • same email already existing as a B2B external user
        • previously soft-deleted user objects
      • The only documented alternatives for creating users outside sign-in-time creation are:
        • self-registration through the user flow
        • admin or automation-based creation through Microsoft Graph API
    3. Identifier-first instead of clicking the IdP button
      • The supported user-flow model is that identity providers are explicitly added to the user flow and appear on the sign-in page as selectable options.
      • The context states there is no first-class home realm discovery in External ID user flows and that silent discovery of the correct IdP based on email domain is not supported today.
      • So there is no supported way in user flows to get the same auto-provisioning by having the user type an email on an identifier-first page and then automatically route to the correct custom OIDC provider.

    Supported options from the context:

    • If federated first-sign-in auto-creation is required, keep the federated IdP enabled in the sign-up/sign-in user flow and do not disable sign-up in a way that blocks account creation.
    • If sign-up must remain disabled, the supported alternative is to create users ahead of time with Microsoft Graph API.
    • If a custom UX is used, domain-based routing can be implemented in the application UI, but federated sign-in for these providers still relies on the browser-based flow and does not change the platform limitation around disabled sign-up.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.