Azure AD B2C to Entra External ID migration: interactive custom step during sign-in with session-persisted context

We have a reasonably complex CIAM architecture and are currently exploring options for migrating from Azure AD B2C to Entra External ID (or potentially another CIAM platform if External ID cannot support some of our requirements).

Our initial discovery has identified journey extensibility as a potential migration challenge. We currently make significant use of Azure AD B2C custom policies, and External ID does not appear to provide equivalent orchestration capabilities. Below is an example of one particular scenario that is important to us.

We have introduced a new authorisation model to support our future requirements, while also needing to support a large estate of legacy applications whose authorisation model has incompatible semantics. Our Azure AD B2C journeys currently act as a compatibility/anti-corruption layer between these two models.

In the new model, a customer can have relationships with multiple organisations, and newer applications understand this natively. Legacy applications, however, can operate in the context of only one organisation at a time.

For a legacy application, our current B2C journey therefore behaves roughly as follows:

1. The customer authenticates.
2. B2C determines the organisations with which the customer has a relationship.
3. If there is more than one applicable relationship, B2C inserts an interactive step into the journey asking the customer to select the organisation in whose context they wish to act.
4. The selected relationship context is persisted in the B2C SSO session.
5. Claims representing that selected context are included when tokens are issued to legacy applications.
6. When the customer subsequently moves to another legacy application using SSO, the previously selected relationship context is retrieved from the B2C session, so the customer is not prompted to select it again.

The selected relationship is deliberately session state rather than user profile state. A customer may legitimately have multiple relationships, and the selection represents the context in which that particular browser session is currently acting.

We are trying to determine whether Entra External ID can reproduce these semantics.

We are aware of Custom Authentication Extensions such as OnTokenIssuanceStart, but our understanding is that these allow server-side logic to execute at defined points in the journey and do not allow us to interrupt an established sign-in transaction, present arbitrary interactive UI to the customer, and then resume the transaction with the resulting state persisted into the SSO session.

Our requirements are therefore specifically:

• conditionally interrupt a sign-in journey before token issuance
• redirect/present custom interactive UI to collect a contextual selection
• resume the original authentication/authorisation transaction afterwards
• persist the resulting context as session-scoped state across SSO between applications
• use that context when issuing claims to the target application

Is there a currently supported way of implementing this pattern in Entra External ID?

If not, is there a recommended architecture for customers migrating from B2C custom policies that have this type of interactive orchestration requirement?

And, to the extent Microsoft can comment on future capabilities, is an extensibility model supporting this category of scenario planned for External ID?

We do not necessarily require a like-for-like replacement for B2C custom policies. A more constrained extensibility mechanism would be sufficient, for example, the ability for a sign-in extension to suspend the current transaction, redirect the browser to an application-controlled interaction, and then securely resume the transaction afterwards. Auth0 Actions' redirect/continue capability is an example of the type of extensibility that could satisfy this requirement.

We would particularly welcome guidance on whether this scenario is expected to be achievable natively in External ID, or whether we should plan for a separate federation/authorisation broker to provide this compatibility layer during our migration from B2C.