Mix and match with user flows and custom policies in Azure AD B2C

Rory Braybrook
The new control plane
2 min readMay 24, 2024
Image of “Mix and match”
YG Entertainment, CC BY-SA 4.0 via Wikimedia Commons

Whenever new B2C users ask me whether to start with custom policies or user flows, I always tell them to start with custom policies.

Among the reasons:

  • You can do a lot more with custom policies in terms of workflows
  • Most users soon find that they “outgrow” user flows and need more functionality
  • In custom policies, you can call API whenever you want
  • You cannot mix and match the users created in one via federation with the other

e.g. if you create a user in a built-in policy via federation, you cannot sign in via federation with that user in a custom policy

This is described here in a question I asked a while back on stackoverflow on this topic.

“The issuer will be different (login.microsoftonline.com vs sts.windows.net). The combination of Issuer and AAD objectId is used to create and locate the user. Due to the mismatch, a user signed up via AAD federation with a user flow can’t sign in via custom policy, account won’t be found.”

I wondered if this was still true?

I ran the following tests:

  • Create a user in a signup user flow. User can log in via a sign-in custom policy flow.
  • Create a user in a signup custom policy. User can log in via a sign-in user flow.
  • Create a shadow user via a federation with Entra ID using a user flow. User can log in via a sign-in custom policy flow.
  • Create a shadow user via a federation with Entra ID using a custom policy flow. User can log in via a sign-in user flow.

In both federation cases, the issuer was:

https://login.microsoftonline.com/<Entra ID tenant ID>

Good to see that the issue has now been resolved.

All good!

--

--

Rory Braybrook
The new control plane

NZ Microsoft Identity dude and MVP. Azure AD/B2C/ADFS/Auth0/identityserver. StackOverflow: https://bit.ly/2XU4yvJ Presentations: http://bit.ly/334ZPt5