What are the basic principles of registration and authorization through OAuth2 social networks?

Question

Social media

Hello.
With the usual registration and authorization, everything is clear.
Registration.
1) We get the username and password from the user.
2) Save to the database.
3) We use its ID for our own purposes (orders in an online store, etc.)
Authorization.
1) We ask the user for a username and password.
2) If they are found in the database, then we create a session.
3) We all work with the same ID (display personal information, work with it)
But what about registration, authorization through social networks, combining standard registration with social networks. networks? What should be stored in the database, is it necessary at all? How to work with it? Outline the algorithm.

Answer 1

I will answer myself.
There is some useful specific information about the technical implementation here.
In short, then...
For authorization, registration, the same 'users' table is used. Together with the usual registration and authorization, when during registration (in the simplest form) the user's email, password and login are added to the 'users' table, and during authorization the compliance of the entered login and password with the existing ones in the database is checked, similarly it is used and registration/authorization through social networks. Only in this case, the source of data about the user for his registration is not the direct user who enters data into the form, but social. network. Registration in this case is quite transparent, ie. not visible to the user. The scheme is approximately the following (without the features of the Oauth protocol):
1) The user selects the entrance through the social. network.
2) There is an appeal to the authorization page in this social network. network, if the person has not yet authorized there. After entering the data, and if he has previously authorized, there is a request for permission to use his data.
3) If a person refuses, then this is the end. If he agrees, he is redirected to the site page specified in the Oauth settings.
4)Each user in the social. networks have their own unique identifier that can be requested. For your 'users' table, you need to add a couple of additional fields (for example, these): auth_via (enum('native, 'vk', 'mailru', '...')) - to indicate the type of user registration, and social_id - a unique identifier in the social will be stored here. networks. If you need to store some specific data of this user from the social. networks, you can create additional. fields for this data.
5)After the user has given permission to use his data, you need to request the necessary data from the social network. networks, incl. and user ID in the social. networks. This is where the invisible registration process begins. You need to check if there is a user in the database with such a social_id, if not, then insert the social_id, user data from the social. networks, if necessary, in the database. Everything, the user is registered.
If there is data about the user, then you need to request relevant data from the social. networks, compare them with those in the database, and if they have changed, then update them in your database, if not, then just go to the next step.
Thus, the existing table of "native" registration of site users is joined, relatively speaking, by a table, the fields necessary for registration / authorization through social networks. networks., and they do not interfere with each other.
For a user registered from the social. network password and login, of course, no. They are required for authorization. And since the user logs in using his username and password in the social. network, then there is nothing to indicate here. And yet, during authorization, to the login and password verification request, add a condition
to exclude users registered from the social. networks.
As you can see, for each user in the table, an internal (intra-site, so to speak) primary, auto-increment key is created. Accordingly, there is no difference for the site logic between a user registered through a social network. network and through the site. If we talk about an online store, then, to bind orders to a user, you can use a single, internal ID.

Answer 2

habrahabr.ru/post/77648
I usually have 2 additional provider fields in the database: vk, facebook, twitter and a unique identifier within the framework of the authorization provider.