How to design third-party account logins such as QQ and WeChat?

Unified login for multiple accounts

Name explanation

The multi-account here is different from the system level. The multi-account system we are talking about means that in our Internet applications, our applications will use multiple third-party accounts to log in, such as the commonly used APPs: Netease, WeChat, QQ, etc. Wait.

Contents of this article

Details of the technical scheme of the multi-account system, as well as the corresponding table design and process design.

Architecture evolution

Early

It boils down to the initial stage because the number of users is relatively small at this time, and there is not even access to the other third-party account systems mentioned above. Only the self-built system can be satisfied. The self-built system is currently commonly used:

Username Password Registration Login

This method will be used in many initial website constructions. Register first, then log in. This shadow can be found in the older cms.

• flow chart:
  
• Flow Description:
  1. The front end sends the user name and password to the server, and the server performs routine judgments to determine whether the length of the user name and password meets the conditions and whether the user name is repeated. If the conditions are not passed, the corresponding error code is directly returned to the front end. Here, the password field, In order to prevent being intercepted during transmission, it is recommended to encrypt and upload again. By default, our transmission password will be encrypted with an md5, and then recorded in the database for another layer of encryption. Even if it is off the database, it will be fine, and the password should not be stored in plain text.
  2. After the verification is passed, the user name and password will be written into the database, and the following operations such as issuing points will not be expanded here.
  3. Now log in. The front end sends the user name and password to the server. The server first verifies whether the number of logins exceeds the set threshold. If it exceeds, it can only continue to wait for the small black house to be shut down.
  4. If the log-in logic is not exceeded, judge whether the user name and password are correct. If the password is incorrect, then the threshold will be judged. If it exceeds, the small black house will be closed. Remember that the small black house must be set with an expiration time, otherwise it will be closed permanently. Yes, this can be done with the expiration of redis.
  5. After successfully logging in, perform all subsequent post-logic, such as adding points... and other operations.

Mobile phone number registration and login

• flow chart
  
• Flow Description:
  1. First enter the mobile phone number and send it to the server. The server records the mobile phone number in our database, then generates a random verification code, binds the mobile phone number and the verification code to a redis, and then records the expiration time, this The expiration time is generally about 10 minutes, which is the validity period of our general mobile phone verification code.
  2. After the mobile phone receives the mobile phone text message, then fill in the verification code on the interface and send it to the server. After receiving the verification code, the server will query the verification code corresponding to the mobile phone number in redis, and return an error code if it fails.
  Log in after success.
  3. It seems that there is no clear registration and login operation here. In fact, sending the mobile phone number can be regarded as a regular registration, and then the following verification code input is a login operation.

: What if I want a password?
Answer: Add a "mobile phone number password supplement function" in the follow-up product. This is also a very common method now, but in the era of the mobile Internet explosion, the password is not so important anymore. If the mobile phone number can be operated app, you can operate without a password.

Database Design

Table Structure:

Self-increasing id	username	password	phone number	Number of errors
1	user1	7fef6171469e80d32c0559f88b377245	13456789012	0
2	user2	7fef6171469e80d32c0559f88b377245	13456789013	0

Description:
Here is just a simple description of the data that needs to be used, without expanding the specific scenario, this table structure can meet the design of the above two schemes.

Introduce a third-party account plan

Here is the login logic of QQ-SDK, let’s take a look at the sequence diagram first:

• Description:
  1. The client itself calls up the login interface, and enters the user name and password. Here is the third party user name and password. After the login is successful, it will return access_token openid expire_in. This process will use oauth2.0, but in The built-in callback is obtained in the sdk, and we will explain our own implementation of oauth2.0 later
  2. The client gets access_token, openid, login_type (qq, wechat...) and requests the application server. After the application server gets these data, it will go to the corresponding user center to verify the access_token and openid according to the corresponding login_type. If the check fails, the corresponding error code will be returned
  3. After the verification is passed, it will be judged whether the login_type and openid exist locally, and if they do not exist, the remote user name, avatar and other basic information will be obtained as the local basic data, and the code value will be returned.
  4. If it already exists, it will log in and return the code value.
  5. After the client gets the code value, it exchanges the token value. This completely complies with the oauth2.0 protocol. Every subsequent request must bring the token. The token value will take a long time on the server because we want to do it. This is the kind of operation that never goes offline, so we accumulate the token expiration time for each request.

Database Design

User base table (users)
Field	Remarks
user_id	User id
token	User login token
expire_in	token expiration time
try_times	Number of failed logins

User authentication association table (user_auth_rel)
Field	Remarks
id	Self-increasing id
user_id	User id
auth_id	Verification table id
auth_type	Authentication type (local, third)

Local user table (user_local_auth)
Field	Remarks
auth_id	Authentication id, self-increment id
user_name	Unique user ID
password	user password
mobile	User phone

Third-party user table (user_third_auth)
Field	Remarks
auth_id	User id
openid	Unique identification of third-party users
login_type	Third-party platform identification (qq, wechat...)
access_token	Access_token obtained by a third party, verify and use

• Description
  1. The users table is only for the login of our business side, mainly for the oauth2.0 business of our own business.
  2. user_local_auth is to log in with your own user name, password, and mobile phone number login information.
  3. user_third_auth is the data record of our third-party user system,
  4. user_auth_rel is used to associate our users table with user_local_auth and user_third_auth.
  5. The whole design concept is to distinguish self-built users from third parties in terms of storage. This is also reasonable in terms of architecture evolution. At the beginning, most user systems are self-built, and then external access.

to sum up

1. In general, the access technology of third-party users is relatively simple. The design of one more user_thirds here can support enough third-party access. Of course, we usually only log in two or three, too. Multi-login parties not only increase their own maintenance costs, but also the interface display is not good-looking.
2. The design scheme here does not include sub-tables and sub-databases, and is not service-oriented. It is a simple and straightforward design.