Azure AD B2C, How to Avoid / Validate, duplicate Sign up with Social Identity Providers
Hi, Assume, I sign up with Google 'email@example.com', it creates a user in the tenant. I sign up with Facebook 'firstname.lastname@example.org', it creates another user in the tenant. Also I went and Sign up using email account, for 'email@example.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 ?
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
Jesus Santander commented
Any news? I'm starting to regret choosing AD B2C, it feels an incomplete/abandoned product.
Any news, please? It is unbelievable that B2C doesn't give this service.
PAILLASSE SYLVAIN commented
Any news please?
Jignesh Patel commented
Any update on this thread? How can we keep Email address unique across all identity provider?
Performing that check based on email would also be sufficient for me.
De-duplicating on email address would be sufficient. A customer using different ways to log in but all accounts having the same email address should be treated as one account with 3 identity providers.
Bartosz Mróz commented
In my opinion it is very important feature for business apps where duplicated email addresses could disturb in business app logic.
Kris Sebesta commented
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
How about an update on this Microsoft? IT HAS BEEN THREE YEARS SINCE THE ORIGINAL POST! Top notch service I tell ya! ... pathetic.
Pradeep Pednekar commented
Any update on this as we are also having same issue.
Eredis Gutierrez commented
Any updates on this?
Raj Gupta commented
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?
Jonathan McElroy commented
Can we get some more information from microsoft about this? Seems pretty standard to check based on email.
when is this being added? Half way through 2018 now
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.
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.
The way forward appears to be the Identity Experience Framework. This was how I got it to work but it isn't ready for RTM yet.
Jeremy Whiteley commented
Any update on this? This has been discussed for two years now!
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.