Is it difficult to switch from Loginza to a native oAuth provider?

Question

OAuth

I hired a programmer who writes a website. Authorization through Loginza is now implemented, but I want to abandon it in the future in favor of the built-in module. However, I am afraid that after changing the authorization system, users will not be able to log in or other kinds of problems will arise.

I'm just afraid that I might run into problems running a site with a login.

Also tell me how best to implement a bunch of accounts. For example, a person enters the site through vk, and then starts using google. How to make a person be able to use his old one instead of a new account?

At the same time, it is logical to assume that if the user is asked to specify all the oAuth providers he uses, he may simply not do this.

Answer 1

I think the refusal is not so terrible, you just need to write your login so to speak :) but taking into account the fact that you will now save the data received from Loginza in the database. Then just work with them.
But for a bunch of accounts, I would do something in the profile similar to the general page of user accounts, and if necessary, he attaches them to the profile, if not, then no. Those. the database structure should contain a user profile table and external accounts are already hooked to it. The main thing is to think over the storage model well, and then rely on it. But the task is not so difficult.

Answer 2

For a bunch of accounts, I would suggest the following logic: the user logs in using a new oAuth provider, a new account is created for him. During login, the system receives the user's basic data (first name, last name, email). You need to notify the user that a new account has been created for him, but if he has already logged in here under a different provider, then he can link his new account to the old one. If by coincidence of first name + last name or email there is another account in the system, it is immediately proposed to link accounts. To confirm that the account belongs to the user, you need to log in using the oAuth that he used before. If the user cannot do this, you must provide another option, for example, indicate the answer to the security question asked on your site or remember other account details of your choice, to make sure it's not the same name. The most extreme case is the “report to support” button, which will send a message to the administrator that the user wants to link two accounts so that a person checks and makes the link.
I did not work with the login, but in theory it should transparently provide all the oAuth data (in this case, there should be no problems). If it itself acts as oAuth and does not show account data from other oAuth providers through which users logged in, then authorization should be done according to the principle described above, just treat the login as another oAuth provider and also look for matches in the data provided by the user.