Identities created from external source allow duplicate email addresses about active-directory-b2c-advanced-policies HOT 4 CLOSED

The signInNames property is reserved for local accounts. Any email addresses stored in this property can be used with a password to sign the user in, without having to go to the social IDP. Therefore, the email addresses of social IDP users are stored in another property (otherMails) that is currently exposed through AD Graph.

Depending on a user's setting, an app's permissions or the IDP, a user's email address may never be sent in the token by the IDP. These policies are designed to work with the user id provided by the social IDP as the primary identifier, and without email address being sent in the token. That is why email is not relied upon.

Another aspect is that some social IDPs permit unverified email addresses on accounts, which could be sent in the token. Therefore, even if available, the default policies do no rely on email addresses since a malicious user can create a social IDP account with another user's email without verification and use it to take over another account.

However, if business rules require, these policies can be modified to check whether an email is verified by IDP and then rely on it for the kind of scenarios you mention. But that could adversely impact the number of users that can successfully sign up and sign in.

from active-directory-b2c-advanced-policies.

Record created with internal idp:

...snip...
  "odata.type": "Microsoft.DirectoryServices.User",
  "objectType": "User",
  "objectId": "1a526ff3-698c-471c-a220-0c336bfe066d",
  "deletionTimestamp": null,
  "accountEnabled": true,
  "signInNames": [
    {
      "type": "emailAddress",
      "value": "[email protected]"
    }
  ],
  "assignedLicenses": [],
  "assignedPlans": [],

Record created with external idp:

  "objectId": "37fa11b0-4423-44cb-8273-2be58deee081",
  "deletionTimestamp": null,
  "accountEnabled": false,
  "signInNames": [],
  "assignedLicenses": [],
  "assignedPlans": [],
  "city": null,
  "companyName": null,

SignInNames is an empty array from the external idp.

from active-directory-b2c-advanced-policies.

@omer-iqbal can you help with this?

from active-directory-b2c-advanced-policies.

However, if business rules require, these policies can be modified to check whether an email is verified by IDP and then rely on it for the kind of scenarios you mention. But that could adversely impact the number of users that can successfully sign up and sign in.

Thanks for the reply @omer-iqbal

Are there any examples/snippets on how we might accomplish this? We're not currently using any social logins, we're only using local accounts and an external (oracle) identity provider for employees.

from active-directory-b2c-advanced-policies.