Hello,
I’m setting up a database similar to what you want, the only difference is that in my application, the user will be able to log in both by Facebook, by Google or by my app’s own authentication system, and if the accounts (Facebook, Google, my App) belong to the same owner (detected via email), so they will have the same single user in the application. I am modeling the database to support, regardless of how many authentication means I will use.
In my case, a same user can have 2 accounts, ex: Facebook, Google. Or even 3 accounts, ex: Facebook, Google, My App.
Explaining how it works: Each user "user" can have one or more "Identity", "Identity" is a connection medium used by the user. In the "Identity" table, there is the "user_id" column that points to the user, the "Adapter" column indicates which medium is used (facebook,google,meu_app), and in "hash", the user ID is stored that is returned by Facebook or Google when using their Apis. In case it is an access by the login system of your application (meu_app), then the hash will store the password that it registered, encrypted with bcrypt, in my case.
At the time of login, you must purchase the access email, either by your application (inserted by your login system), or 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 that the user already exists, right? In this case you will get the ID of this user will check if there is also an "Identity" for the used connection medium. For this check if the "Adapter" matches, if it matches well, check that the "hash" also matches, if it matches, cool! It means that the user already has an account, and has already logged in using that medium. 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 don’t think I answered your main questions. So here goes:
For the first question, I think what I wrote above answers. I put an image too.
For the second question, I see no need to make the user fill in username and password, in fact it does not make sense, considering that if the user chose to login through Facebook, it is because he does not want to keep creating username and password. In addition, this whole login process is done in a secure Facebook environment, the API takes care of all this, you only need to take care of the part of storing the user in the BD if the connection is successful. What might be 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!
There are 4 votes to close your question as "mostly based on opinions". I disagree, because in my opinion your questions are punctual doubts about the behavior of the facebook API and how to proceed with it. However, I agree that the original wording of the question could be improved, because the way it was, it even invited some reader to answer opinionated, although it is not the purpose. I edited the question to solve this and avoid closing.
– Victor Stafusa