This recipe is responsible for linking emailpassword
and thirdparty
recipe together.
RecipeID: emailpassword-thirdparty
thirdparty
+ emailpassword
There is no account consolidation between third party and email password! They just live together side by side.
[x] If a user signs up with third party, then is it possible for them to follow the reset password flow and then sign in with email password?
[ ] If a user signs up with email password, and then sign in with a social login (with the same email), should that be allowed?
[ ] Should we have a separate sign in / sign up section
[ ] What happens in case of a user using one 3rd party , that login is removed, and then they want to sign in with their email ID, but have no password...
[ ] How will email verification work here?
[ ] If I’m signing in using email id and password as I don’t remember what social login I signed up last with what will I put in password field? Should it check if this email Id exists in a special database and then avoid showing password field and ask for OTP?
[ ] If I sign up using email id and password, but do not verify my email. Then after few days I come back and try to sign in using google login which has the same email as the one I used to sign up previously, what will happen?
[ ] If I have already signed up using google login, and then if next time I try to sign in using the same email id and password should it be able to sign me in? Meaning, should we store that data in the backend and cross check?
[ ] How will deletion of a user work?
[ ] Should we have a guide for our customers to find "What kind of login should I have for my app?" For apps that need high security, but have customers that aren’t too tech savvy, I would recommend a passwordless option. So something that help people realize + improves our overall UX. I'm pretty sure many companies spent hours agonising the kind of approach they should take over building login. Should discuss with @Advait Ruia
[ ] Why don't we have one recipe to link emailPassword with Session?