Should the `admin` create user handler of Auth create identities based on the provider under the hood? about auth HOT 3 CLOSED

hi @rexwangcc,

Is this by design? I.e. Supabase Auth always tends to create a email identity no matter what provider is specified when creating a user via admin endpoints.

The admin user create endpoint requires either an email or phone number to be passed in - there is an assumption made here that the user created will have either an email / phone identity, depending on which one was provided initially.

If this is by design, can we assume that we can just let it be and don't have to poke anything with the auth.identities table, and simply let the user's first login updates the DB?

Yes, that's fine because when the user signs in with google, there will be a new google identity created and it will be linked to the user since they share the same email.

Then what does the provider=email record in auth.identities do at all? I tried deleting it from the underlying DB table and still being able to login with Email OTP.

Currently, it doesn't enforce anything but eventually, the goal is to decouple having unique emails for OAuth identities (see #214).

from auth.

closing this issue since it's more of a question

from auth.

closing this issue since it's more of a question

Thanks for the reply / help! We ended up leaving the "redundant" provider=email record in auth.identities table for now.

from auth.