Azure B2C is a large membership database which also provides the features of tokens, sessions and membership/authentication experience (sign-up, sign-in, forget password and etc). But there are some scenarios which are little tricky based on how the entire solution is handled. Let me explain such a use case and describe different ways to handle that in B2C.

Case : You have an application which is a reselling portal, where a user can either be a seller or a buyer. During the registration / sign-up process user type will automatically be detected by the application, thus the user does not need to select the type. The below diagram explains the case.

Question: In this case why we cannot pass the parameters from step 1which holds the user type value and populate that value in a hidden field in the custom.html or the rendered mobile view in step 2. So it is straight forward to persist that information in B2C.

Answer: Since the rendering is controlled by B2C, any script execution is not allowed in that context. (I’m not sure is there any way to do this). Also the same html view is rendered in mobile or any other native clients passing the information from step 1 to step 2 in any means is not a safe option even if it is possible in any manner.

So we end up having the trouble of passing the user type information from step 1 to step 2 and instruct the B2C to persist that information.

Solutions:

There are different solutions. The trade off is always between how much of control we’re going to take from B2C and how much of control we let the B2C to have. This comes with the cost of development effort and control.

Solution 1: Let B2C handle the case much as possible and application controlled fields like user type to be saved in custom database column. And optionally update the B2C custom attribute using Graph API. Figure 2 explains this.

In this way, we get the benefits of the B2C policies and how to handle the auxiliary authentication services like password management, profiles offered by B2C. Most applications follow this without updating the B2C back using the Graph API.

Solution 2: Take control from B2C to the custom application and use B2C as a membership database.

In this model – In the step 1 some custom attribute values are determined (ex – user type) and passed to the step 2 which is a view controlled purely by the developer. Then step 2 passes the information to the application API in step 3. Server application updates B2C in step 4 and receives the JWT token in step 5. Application updates the database with the oid and other parameters in step 6.

What B2C could do in the future

In the current state of B2C – B2C has applications and policies. Applications and policies can be used many combinations. One application can have many policies of the same type with different settings and also one policy can be used across many applications as well.

In the custom rendering B2C should allow to have hide attributes with the default values. In that way in modeling the above scenario we can have have different policies with different settings and default values.

Primary critical requirement is in the below screen that B2C should add are..

1. show/hide fields
2. set default values