Unified multi-account login plan

Unified multi-account login plan

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, and the commonly used APP (NetEase Cloud Music) login method must be used now Including: Netease, WeChat, QQ


Through this article

What you can learn: the details of the technical solution for multiple users, as well as the corresponding table design and process design.

No: Like other articles, I won't have specific code implementation details here, the plan is right, and the code will not be too bad.

Architecture evolution

Early start

It boils down to the early stage of the business because the number of users is relatively small at this time, and the account system of other third parties mentioned above has not even been accessed. Only the self-built system can be satisfied. If you build a self-built system, the current commonly used ones are

Username Password Registration Login

This method will be used in many early website constructions. Register first, then log in. You can find this shadow in the older cms.

flow chart:

Flow Description:

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. The password field here is to prevent The user is 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 library, it is fine, and the password should not be stored in plain text.

After the verification is passed, the user name and password will be written into the database, and subsequent operations such as issuing points will not be expanded here.

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 the threshold, it can only continue to wait to be shut down.

If it does not exceed the log-in logic, judge whether the user name and password are correct, and if the password is incorrect, the threshold will be judged. If it exceeds, the small black room must be closed. Remember that the small black room must be set with an expiration time, otherwise it will be permanently closed. This can be done with the expiration of redis. After the login is successful, all subsequent post logic is performed, such as adding points. . . And so on.

Mobile phone number registration and login

flow chart:

Flow Description:

First enter the phone number, and then send it to the server. The server records the phone number in our database, then generates a random verification code, binds the phone number and the verification code to a redis, and then records the expiration time, this expiration time It is usually about 10 minutes, which is the validity period of our general mobile phone verification code.

After the mobile phone receives the mobile phone text message, then fill in the verification code on the interface and send 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.

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 verification code input is a login operation.

Q: What should I do 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. However, in the era of the mobile Internet explosion, passwords are no longer so important. Anyway, I can never remember the password. If the mobile phone number can operate the app, absolutely do not need a password to operate.

Database Design

Table Structure


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 first come to a sequence diagram


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 SDK Get the built-in callback, we will explain our own implementation of oauth2.0 later

The client gets the 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.

After the verification is passed, it will be judged whether the login_type and openid exist locally. 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.

If it already exists, the login operation is performed and the code value is returned.

After the client gets the code value, it exchanges the token value. This completely complies with the oauth2.0 protocol. Each subsequent request must bring the token. The token value will take a long time on the server side because what we want to do is The kind of operation that never goes offline, so we accumulate the token expiration time every time we request.

Database Design

Table Structure

User base table (users)

User authentication association table (user_auth_rel)

Local user table (user_local_auth)

Third-party user table (user_third_auth)


  • The users table is only for the login of our business side, mainly for the oauth2.0 business of our own business.
  • user_local_auth is to log in with your own username and password, and log in with your mobile phone number.
  • user_third_auth is the data record of our third-party user system,
  • user_auth_rel is used to associate our users table with user_local_auth and user_third_auth.
  • 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.


In general, the access technology for 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 many logins. Not only does the party maintain its own maintenance costs, but the interface is not good to look at.

I hope everyone can learn from the above and have a better understanding of our multi-account login. The design here does not include table and database, no service, it is a simple and straightforward design. Of course, the number of users is different from what you need. There are many things to be added on this basis, thank you for reading! ! !

See here, follow one

Reference: https://cloud.tencent.com/developer/article/1480186 Unified multi-account login solution-Cloud + Community-Tencent Cloud