How can we improve Azure Active Directory?

Azure AD B2C, How to Avoid / Validate, duplicate Sign up with Social Identity Providers

Hi, Assume, I sign up with Google 'siva@gmail.com', it creates a user in the tenant. I sign up with Facebook 'siva@gmail.com', it creates another user in the tenant. Also I went and Sign up using email account, for 'siva@gmail.com', now am finding 3 users with same email id. I see this is a duplicate accounts are getting created. Is there any way this can be validated & inform user in Azure AD B2C ?

193 votes
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)

We’ll send you updates on this idea

Sivalingaamorthy Subramaniam shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thank you. We will examine the experience of duplicate sign ups across Identity providers. Would performing this check by using the email address be sufficient?

BTW, Linking multiple provider accounts to one user is in our roadmap and we’ve already achieved it in preview…

We look forward to your feedback

/Jose Rojas

35 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
  • Kris Sebesta commented  ·   ·  Flag as inappropriate

    Another possible solution is to actually allow the user to have multiple accounts with the same email address. When the user logs in you can use the EmailAddress AND UserPrincipleName (or OID) as a compound key and save them in your application database in a table (say, UserAccounts) that is keyed on EmailAddress AND UserPrincipleName (or OID). Then have the UserAccounts table related (FK) to your primary user table (so you will have one User row and one-to-many UserAccounts rows). We are using the following two lines to get each property in the SecurityTokenValidated notification method.
    var userEmail = context.AuthenticationTicket.Identity.FindFirst("preferred_username"); // Email address.
    var userPrincipleName = context.AuthenticationTicket.Identity.FindFirst(System.Security.Claims.ClaimTypes.NameIdentifier);
    That way, when the user signs-in, the application looks up the user via their EmailAddress AND UserPrincipleName (or OID) and you can identify the one user row in the Users table. Hope this helps someone. Cheers!

  • Kris Sebesta commented  ·   ·  Flag as inappropriate

    How about an update on this Microsoft? IT HAS BEEN THREE YEARS SINCE THE ORIGINAL POST! Top notch service I tell ya! ... pathetic.

  • Raj Gupta commented  ·   ·  Flag as inappropriate

    Our is financial application secured by Azure Ad B2C and because of this issue, that we faced after implementing everything. We are stuck in middle. Can we have any update on this? Please.

    In the meanwhile is there any work around to fix this issue so we can keep things going?

  • Jon commented  ·   ·  Flag as inappropriate

    Can we get some more information from microsoft about this? Seems pretty standard to check based on email.

  • Nik commented  ·   ·  Flag as inappropriate

    Having been using B2C for a year now, we are a couple of weeks from ditching it... its far more restrictive and painful than any value if brings now and progress on fixing anything is glacial to non existent.

  • Steve Whitaker commented  ·   ·  Flag as inappropriate

    The stackoverflow answer I linked to was about missing the emails claims in the policy but the general idea is that you build your own api calls into the process. I added one that calls back via the graph api to check for an existing email addresss but using another provider.

  • Steve Whitaker commented  ·   ·  Flag as inappropriate

    BTW - the comment "Linking multiple provider accounts to one user is in our roadmap and we’ve already achieved it in preview" seems to refer to allowing this scenario after user accounts are migrated from another system rather than any specific feature supporting what is requested here.

  • Steve Whitaker commented  ·   ·  Flag as inappropriate

    I've managed to it working by implementing a custom policy using the User Identity Experience Framework but which isn't GA'd yet and has no timeframe. You can inject a call to an external API which can call back via the Graph API to determine whether another account exists with the same email address. Still nothing built into standard policies yet though.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Unfortunately, this request is not being reviewed or responded for more than one year, is a deal-breaker for us. We give up Azure AD B2C and possibly most of the other services just because this issue. Just FYI.

  • Azadeh Karimian commented  ·   ·  Flag as inappropriate

    We have implemented Azure AD B2C single sign on with both 1. Local account (using username) and 2. Social accounts (google and Facebook). We need to change our Local account setting to get Email instead of username, but in this case if user login using social network , the email address is not unique. Meaning that for example one user can sign up through local account using his email address and he also can sign up through social account through same email address. This will cause duplicate users in our Azure user storage which is a Big problem for us.

    We have to give up sign up with social accounts due to creating duplicate users which is really bad. I hope Microsoft implements a way to check Emails to be unique soon for the scenarios that we need to use both local account and social sign up.

  • Anonymous commented  ·   ·  Flag as inappropriate

    This could be done in the interim using a custom user policy which checks the B2C Azure AD service via Graph for duplicate objects based on email address.

  • drevange commented  ·   ·  Flag as inappropriate

    Yes please add this! Email address is NOT a good way though to tie things together underneath as people can have different email addresses and can change them. I can't tell you the number of horror stories of those trying to make email address the identifier.

    Having a "sanity check" though by email address would be the best thing. If you try to sign up with the same email address is should prompt for confirming an existing account. :)

    But the underlying id should never be email address

  • Jay Van der Zant commented  ·   ·  Flag as inappropriate

    This is a pretty basic requirement. The email address is the consistency key among services, so should ensure uniqueness. When someone signs in with a new type of social account, that should be added to their existing identity.

    At least that's how I've extended ASP.NET Identity to work. You can't expect users to remember how they signed in before. One day they may sign-in with Gmail, the next Facebook.

← Previous 1

Feedback and Knowledge Base