Design and Implementation of a Multi‑Account Login System with Third‑Party Integration

Terminology

The multi‑account concept here differs from system‑level accounts; it refers to internet applications that allow users to log in with multiple third‑party accounts such as NetEase, WeChat, and QQ.

Content

Through this article you can learn the technical details of multi‑user solutions, including table design and process flow. No concrete code is provided, but the design principles are sound.

Architecture Evolution

Early Stage of Startup

When user volume is low and no third‑party accounts are integrated, a self‑built system suffices. Common early‑stage solutions include:

Username & Password Registration/Login

This method is widely used in early websites: users register first, then log in. The flow is illustrated below.

Flowchart:

Process Description: The front end sends username and password to the server, which validates length, uniqueness, etc. Passwords should be encrypted (e.g., MD5) before transmission and stored with an additional hash. After validation, the credentials are saved to the database and subsequent business logic (e.g., awarding points) proceeds.

During login, the server first checks whether the login attempts exceed a configured threshold; if so, the account is temporarily locked (e.g., using Redis expiration). If not, the credentials are verified, and on success the post‑login logic (such as adding points) is executed.

Phone Number Registration/Login

Flowchart:

Process Description: The user enters a phone number, which is stored in the database. A random verification code is generated, bound to the phone number in Redis with a typical 10‑minute expiry, and sent via SMS. The user submits the code; the server validates it against Redis. Successful verification logs the user in. The phone number entry itself acts as registration, while the code entry serves as login.

For password handling, a later feature can allow users to set a password for the phone‑number account, though many modern apps rely solely on phone verification.

Database Design

Table Structure

Explanation: The diagram shows the tables needed for the two login schemes described above; the structure can satisfy both.

Introducing Third‑Party Account Scheme

The following sequence diagram illustrates QQ‑SDK login flow.

Explanation: The client initiates the third‑party login UI, the user enters the third‑party credentials, and upon success receives an access_token , openid , and expire_in (OAuth2.0). The client then sends these values plus login_type (e.g., qq, wechat) to the application server.

The server validates the token and openid with the corresponding user center. If validation fails, an error code is returned. If it succeeds, the server checks whether a local record for this login_type and openid exists. If not, it fetches basic user info (username, avatar) from the third‑party service, creates local records, and returns a code . If the record already exists, the server simply logs the user in and returns a code .

The client exchanges the code for a token according to the OAuth2.0 protocol. The token is then attached to subsequent requests; its expiration time is extended on each use to achieve a “never‑log‑out” experience.

Database Design

Table Structure

Users Table (users)

User Authentication Relation Table (user_auth_rel)

Local User Table (user_local_auth)

Third‑Party User Table (user_third_auth)

Explanation:

The users table stores business‑side login information and handles the application’s own OAuth2.0 flow.

user_local_auth records username/password and phone‑number login data.

user_third_auth stores third‑party authentication data.

user_auth_rel links users with user_local_auth and user_third_auth .

This design separates self‑built users from third‑party users, reflecting a natural evolution from a purely internal system to one that integrates external providers.

Summary

In summary, integrating third‑party accounts is technically straightforward; adding a user_third_auth table enables support for many providers, though typically only two or three are used to keep maintenance and UI manageable.

We hope this article gives you a solid understanding of multi‑account login design. The presented solution is a simple, non‑sharded, non‑service‑oriented design; real‑world systems may require additional considerations such as sharding, micro‑services, and scaling.

(End)