Custom Policy: IdentityExperienceFramework vs ProxyIdentityExperienceFramework

Question

When working with Custom Policies in Azure AD B2C, you will typically see two kinds of applications being registered:

• a web API, often called IdentityExperienceFramework
• a native app, often called ProxyIdentityExperienceFramework

To quote from the tutorial on Custom Policies:

Azure AD B2C requires you to register two applications that it uses to sign up and sign in users with local accounts: IdentityExperienceFramework, a web API, and ProxyIdentityExperienceFramework, a native app with delegated permission to the IdentityExperienceFramework app. Your users can sign up with an email address or username and a password to access your tenant-registered applications, which creates a "local account." Local accounts exist only in your Azure AD B2C tenant.

What I have not found yet is a motivation why both applications are needed. All tutorials but also the official documentation skip over it. They only explain the steps for creating and registering the apps, but not their exact purpose.

Questions:

• What is the difference between the IdentityExperienceFramework and the ProxyIdentityExperienceFramework?
• Why are both applications needed in typical flows (e.g., sign-up/sign-in)?
• Are there use cases where Custom Policies require only one of these applications? Or more then these two?

Answer 1

You need both and this is the only option. Services on our side are designed to work using this Native App+Resource app on our end. Also means you don’t need a client secret to be sent as part of the ROPC call that login-noninteractive makes. No, there is no other combination ever used or required.