Unified Multi-Account Login Architecture and Design

Unified Multi-Account Login

Name Explanation

In internet applications, a multi‑account system refers to using several third‑party accounts (e.g., NetEase, WeChat, QQ) for login rather than a single system‑level account.

Content

Through this article you can learn the technical details of multi‑user solutions, including flow diagrams and corresponding table designs, but you will not find concrete code implementations; the design is sound and any code written on top of it will be acceptable.

Architecture Evolution

Early Startup

At the early stage, user volume is small and only a self‑built authentication system is needed.

Username/Password Registration and Login

The typical flow is: the front‑end sends username and password to the server, the server validates length, uniqueness, and encrypts the password (MD5 + additional encryption) before storing it; login attempts are rate‑limited using a threshold stored in Redis, and successful login triggers post‑login business such as awarding points.

Mobile Number Registration and Login

The flow is: the user submits a mobile number, the server stores it, generates a random verification code, and caches the code with the phone number in Redis (usually 10‑minute expiry). The user receives the SMS, submits the code, the server validates it, and upon success the login proceeds. The initial mobile number submission is treated as registration, and the verification step as login.

Database Design

Simple table to support both schemes:

Auto‑increment ID

Username

Password (hashed)

Mobile

Failed Attempts

1

user1

7fef6171469e80d32c0559f88b377245

13456789012

0

2

user2

7fef6171469e80d32c0559f88b377245

13456789013

0

This schema satisfies both the username/password and mobile‑verification approaches.

Third‑Party Account Integration

Using QQ‑SDK as an example, the sequence is:

The client invokes the third‑party login UI and obtains access_token , openid , and expire_in via the SDK (OAuth2.0 flow handled internally).

The client sends these values together with login_type (e.g., qq, wechat) to the application server.

The server validates the token and openid with the corresponding third‑party user center.

If the user does not exist locally, the server fetches basic profile information (username, avatar) and creates a local record, returning a code value.

If the user already exists, the server proceeds with login and returns a code value.

The client exchanges the code for a long‑lived token according to the OAuth2.0 specification; the token’s expiry is refreshed on each request to achieve near‑permanent sessions.

Database Design (Detailed)

Based on community feedback, the following tables are recommended:

Users table (users) – stores business‑side login information and OAuth2.0 tokens.

Field

Remark

user_id

User identifier

token

Login token

expire_in

Token expiry time

try_times

Failed login attempts

User authentication relation table (user_auth_rel) – links the business user to authentication records.

Field

Remark

id

Auto‑increment ID

user_id

Business user ID

auth_id

Authentication record ID

auth_type

Type (local, third)

Local user table (user_local_auth) – stores username/password and mobile information.

Field

Remark

auth_id

Authentication ID (auto‑increment)

user_name

Unique username

password

Hashed password

mobile

Mobile number

Third‑party user table (user_third_auth) – records third‑party credentials.

Field

Remark

auth_id

Authentication ID

openid

Third‑party unique identifier

login_type

Platform identifier (qq, wechat, …)

access_token

Token used for validation

The design separates self‑built users from third‑party accounts, which matches the natural evolution from a pure internal system to an integrated one.

Summary

Third‑party login integration is technically straightforward; adding a generic user_third_auth table enables support for many providers, though in practice only a few are needed to keep UI and maintenance manageable.

The presented design is a simple, non‑sharded, non‑service‑oriented solution that works for moderate traffic; larger scale systems would need further extensions such as sharding, micro‑services, and advanced security measures.