user journey that does not create duplicate accounts about active-directory-b2c-advanced-policies HOT 5 OPEN

It is indeed possible.
At step3, when you get the email address from Facebook, you can make an account discovery in AAD using that email address as username. If it exists, you can merge Facebook account into that existing AAD account. If not, create new AAD account.
Several caveats to be aware when you decide to go with this path

1. Not all users from Facebook provide their email address, when they grant permission to the app, they have an option to not provide email address
2. From security stand of point, you will be relying on Facebook properly verifying the email address of the user. If Facebook allows unverified email address, it can be exploited to gain user access to those existing account.

For your second issue, I assume you are talking about there are already two accounts and you would like to merge them. In the policy, technically you can have a AAD technical profile to delete one account, merge their claims and update the other account. The caveat here is that the relying website need to handle the merge case for example, how to merge the reward points of two users.

We don't care if the user does not have a verified email or is not showing the email in the consent, what we want is a fluid and intuitive user journey for 99% of the cases. As I explained with the documented wingtipgamesb2c example, the current demo policies are not implemented as a good reference and whoever did this docs/examples could fix this with the suggested pre-condition. At least not creating a duplicate AAD entry when the verified email is a match (precondition).
@xinaxu, a great answer would be a link to a commit/fork with the changed parts we need to do in the xml files ;-)
thank you, at least you gave us a light at the end of the tunnel, now we just need to learn how to program profiles using xml.

from active-directory-b2c-advanced-policies.

It is indeed possible.
At step3, when you get the email address from Facebook, you can make an account discovery in AAD using that email address as username. If it exists, you can merge Facebook account into that existing AAD account. If not, create new AAD account.
Several caveats to be aware when you decide to go with this path

1. Not all users from Facebook provide their email address, when they grant permission to the app, they have an option to not provide email address
2. From security stand of point, you will be relying on Facebook properly verifying the email address of the user. If Facebook allows unverified email address, it can be exploited to gain user access to those existing account.

For your second issue, I assume you are talking about there are already two accounts and you would like to merge them. In the policy, technically you can have a AAD technical profile to delete one account, merge their claims and update the other account. The caveat here is that the relying website need to handle the merge case for example, how to merge the reward points of two users.

from active-directory-b2c-advanced-policies.

@xinaxu Is it possible to have an example how to accomplish the step in the policy to do the account discovery in AAD that you suggested?

from active-directory-b2c-advanced-policies.

It can be achieved using Validation Technical Profiles and Preconditions. https://docs.microsoft.com/en-us/azure/active-directory-b2c/validation-technical-profile
You can have 3 validation technical profiles.

1. Get User from AAD using email address, and do not throw error if the user does not exist
2. Link Facebook account to that AAD user. This technical profile is only executed when the objectId exists using Precondition
3. Create new AAD user. This technical profile is only executed when the objectId does not exist using Precondition

from active-directory-b2c-advanced-policies.

@canoas did you eventually manage to get this working? It was the first question from the business "Why are there duplicates created" on a new project I'm working on.

from active-directory-b2c-advanced-policies.