I’m currently in the process of migrating our auth flow from something in house to auth0. Moving kind of slow, but I’m getting there!
This current problem I’m having is how to handle a not-yet-migrated user who tries to login via social sign ins?
As mentioned, our in house authentication flow is being migrated to auth0 via automatic migrations. It’s all working and good, but it only works if the user logs in via the regular email and password input in auth0’s Universal Login.
I’m trying to handle the scenario where a user, who has not been migrated, tries to login to their gmail via Continue with Google which I noticed, so far, creates a google-connection user in User Management.
I found a way to prevent social sign ons via a rule, and I was in the middle of leveraging it to query the custom database first, then if the email exists, prevent the sign on. Alas, I noticed it still creates a user in auth0’s User Management.
Is there a way prevent the creation of a user if they sign on using a social connection should they exist in some custom database?
You might be able to interrupt the creation of the profile using a pre-registration hook. We previously did something similar to prevent new signups from grabbing the username of a not-yet-migrated user. I’m not sure if this will work in conjunction with a social login though (possibly hooks only trigger for DB connections?)
Just thinking out loud here: maybe a Rule that recognizes a target user (legacy tenant Auth0 DB users with attached Google identity), sends the user to a microsite, the microsite authenticates them with their Auth0 database creds and then cleans up / sets up the profile in the new tenant? Sounds like a lot of work but I don’t think there is an easy way to handle this. Also potential issue with users who have forgotten their Auth0 DB creds. Password reset is easy enough but then the whole flow / experience starts to get a bit much.
Thanks for the idea. I found a different idea that might work. I noticed if a user has been migrated then tries to login via a social sign on, I can catch this via account linking.
So, instead of automatic migrations, I could use a bulk migration (which probably would entail some downtime when I roll this out to prod, unfortunately) which would ensure all of our users are in auth0. Then no matter the route of logging in, I should be able to catch an existing user.
What do you think of this idea / do you think it could work?
100% agree. I am a big fan of bulk migration. We’ve used both methods, but ever since Auth0 added support for password hash import via bulk migration, that has been my go-to method. Automatic / lazy / trickle migration is nice, and should be a seamless experience for the user, but you can run into all sorts of corner cases that will cause you grief, enterprise / social login being one of those (automatic migration only triggers for database users).
You probably don’t need me to tell you this but just be sure to consider the security implications of automatic account linking. I think there’s some information about this in the Auth0 docs.
That’s the route I decided we’re going to go with. Do you know much about cryptography? Having a hard time converting our database hash to the string required by the bulk import. We’re using a pdkdf2 function which uses a keylen of 32 and has 29000 iterations.
So given a hash $pbkdf2-sha256$29000$RmiN0VqL0fo/59xbS6l1Dg$pWJJ18l.JrqbHG6XPfUu6w4AUTzpc8kz/74yV7j/zQg
I wrote something to convert it to $pbkdf2-sha256$i=29000,l=32$RmiN0VqL0fo/59xbS6l1Dg$pWJJ18l.JrqbHG6XPfUu6w4AUTzpc8kz/74yV7j/zQg
This succeeds in the import but when I try logging in as that user given the password, it throws a 'wrong email or password` error, so I’m thinking my hash conversion is wrong? I see the user in the user management screen also
Thanks again!
Edit I got it working w/ the bulk importing. The pbkdf2 function im using from python’s passlib encoded it a little differently than required so I decoded it doing what they do, and re-encoded to auth0’s liking and it’s working now
