How to support anonymous users in B2C?

Viewed 193

We require architectural advice for our setup.

We are developing a mobile application which will:

  • Use B2C Authentication
  • Support anonymous users (allowing users to skip the registration process)
  • Still perform a form of Authentication on API requests by using Azure access tokens (if possible)

What we have attempted to implement:

  • Anonymous client - When a user opts to skip the registration process:

    1. Trigger a silent sign-up request to B2C via MS Graph
    2. Populate a custom field with a backend-generated deviceID, which we could later use to recognize the user.
    3. Generate token with the information above

    The user would not have an impression of being registered and no personal data would be collected.

  • (Completely) Registered client - If the user decides to complete the registration,

    1. Start the regular B2C interactive sign-up process and ask the user to enter all required info.
    2. In the background, check if the user exists by sending the previously generated deviceId to B2C and comparing it with the user's entered info.
      • If the user DOES exist
        1. Skip some of the further sign-up steps
        2. Perform a silent profile update via Graph using our API with the deviceID and user's data.
      • If the user DOES NOT exist (User was completing the sign-up for the first time, after installing the app)
        1. Proceed with the normal sign-up flow

This seemed like something which could be achieved using custom policies and using the id_token_hint which would contain the deviceId and be sent in an inbound JWT from our API to the B2C. In the policy, we would add an extra orchestration step to the user journey for extracting the deviceId and passing it on to be used in the validation orchestration step.

However, this seems far too complicated and so far we had no success in making this work. Therefore, we would kindly ask for your advice on the matter.

Is there an out-of-the-box solution which covers this sort of scenario?

Some feature which would support the concept of 'temporary application users'.

If not, what would be the correct outline of steps needed to make this work?

1 Answers

You can build this using two flows. I am assuming that the deviceId is generated client side, based off the browser and other signals.

Guest user flow
This flow would allow a user to "checkout as guest", lets say. When the user clicks this, launch the Guest user B2C policy.

  1. Your app should generate the deviceId using client side javascript
  2. Your app should send this data as a query parameter to the Azure AD B2C Guest user B2C policy.
  3. The Guest user B2C policy should resolve the deviceId query parameter
  4. The Guest user B2C policy should write an account with a randomly generated email using a claimsTransform, and also write the deviceId to the signInNames.deviceId attribute. This allows looking up the account by deviceId
  5. The Guest user B2C policy should then issue a token for this user account, and should also embed the deviceId as a claim in the token.
  6. Your app may set a persistant cookie with the deviceId. That allows the device to be recognized even if the user closes the browser or logs out. Optional.

Guest conversion flow
Later the user, whilst still logged in, wants to finish setting up their account. Create a new B2C policy, this time we will pass the deviceId into the query parameter, if the app has one available (either in the token, or app cookie).

  1. Your app should check if the token contains a guest user, with deviceId. If not, check if a cookie is present with the deviceId.
  2. Your app should make an authentication request to AAD B2C, with the deviceId in the query parameter
  3. The B2C policy should resolve the deviceId query parameter
  4. The B2C policy should do a lookup in the directory by signInNames.deviceId with the deviceId resolved from the query parameter
  5. If a user is found, operate against this objectId for further steps
  6. If a user is not found, do the normal sign up steps

All of the above can be converted to use id_token_hint if you like, that will mean nobody can mess with the deviceId that is sent to AAD B2C, as it will become a signed value.

You will also want to think about deviceId collision. If that is possible, then this become a security issue, as two different people may become linked to the same account.

Related