Hello,
I'msettingupadatabasethatlookslikewhatyouwant,theonlydifferenceisthatinmyapplication,theusercanloginviaFacebook,Google,ormyapplication'sauthenticationsystem,andiftheaccounts(Facebook,Google,myApp)belongtothesameowner(detectedviaemail),sotheywillhavethesamesingleuserintheapplication.Iammodelingthedatabasetosupport,regardlessofhowmanyauthenticationmediaIwilluse.
Inmycase,thesameusercanhave2accounts,ex:Facebook,Google.Oreven3accounts,ex:Facebook,Google,MyApp.
Explaininghowitworks:Eachuser"user" can have one or more "identity", cade "identity" is a means of connection used by the user. In the "identity" table, there is the "user_id" column that points to the user, the column "adapter" indicates the medium used (facebook, google, my_app), and hash is stored the user ID that is returned by Facebook or Google when using their APIs. In case it is an access through your own login system (my_app), then the hash will store the password that it has registered, encrypted with bCrypt, in my case.
At the time of login, you must acquire the access email, either by your application (inserted by your login system), ie by Facebook or Google, their own API returns the email as well. So, in the login logic of your REST service, you should check if this email already exists in the "user" table, because if it is, it means the user already exists, right? In this case you will get the ID of this user will check if there already exists an "identity" for the connection medium used. To do this, make sure the adapter matches, if it matches well, check that the hash also matches, if it matches, legal! It means that the user already has an account, and logged in using that account. If you do not have this "identity" then you must register. The same is true if the user does not exist, then you will have to register both the user and the identity itself.
Editing: I talked and talked and I do not think I answered your main questions. So here goes:
For the first question, I think what I wrote above answers. I put a picture too.
For the second doubt, I do not see need to make the user fill in username and password, it does not really make sense, considering that if the user has chosen to sign in via Facebook, it is because he does not want to be creating user and password. In addition, this entire login process is done in a secure Facebook environment, the API takes care of all this, you just need to take care of the part of storing the user in the DB if the connection succeeds. What is perhaps interesting to do, is a step to finalize the registration, if you want to know some additional information that is not returned by Facebook.
Any questions or suggestions, I'll be following!