Unified Multi‑Account Login: Architecture, Flow, and Database Design

Unified Multi‑Account Login

Name Explanation

In this context, "multi‑account" refers to using several third‑party accounts (e.g., NetEase, WeChat, QQ) to log into an internet application, not system‑level accounts.

Content Overview

The article teaches the technical details and table designs for multi‑user login, but does not provide concrete code implementations.

Architecture Evolution

Startup Phase

Username & Password Registration & Login

This is a common early‑stage approach where users first register with a username and password, then log in.

Process:

Frontend sends username and password to the server; the server validates length, uniqueness, and encrypts the password (MD5 + additional encryption) before storing it.

After successful validation, the credentials are saved to the database and any post‑registration actions (e.g., awarding points) are performed.

During login, the server checks login attempt thresholds (e.g., using Redis expiration) to prevent brute‑force attacks.

If the credentials are correct, the user is logged in; otherwise, the failure count is incremented and may trigger a temporary lockout.

Successful login triggers subsequent business logic such as awarding points.

Mobile Number Registration & Login

Process:

User submits a mobile number; the server stores it, generates a random verification code, and caches the code with the phone number in Redis (default expiry ~10 minutes).

User receives the SMS code, enters it, and the server validates the code against Redis.

Upon successful verification, the login is considered successful.

In practice, sending the mobile number acts as a registration step, and the verification code entry serves as the login step.

Q: What about passwords?

A: Add a "mobile number password supplement" feature later; many modern apps rely primarily on mobile verification and deem passwords less critical.

Database Design (Basic Table)

Auto‑increment ID

Username

Password

Mobile

Error Count

1

user1

7fef6171469e80d32c0559f88b377245

13456789012

0

2

user2

7fef6171469e80d32c0559f88b377245

13456789013

0

This simple schema supports both the username/password and mobile‑based flows.

Third‑Party Account Integration (QQ SDK Example)

The client initiates the QQ login UI, obtains access_token , openid , and expire_in via OAuth2.0, then sends them along with login_type to the application server.

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

If validation succeeds, the server checks whether this login_type and openid already exist locally.

If not, it fetches the remote user’s basic info (e.g., nickname, avatar) and creates local records, returning a code value.

If the record exists, it proceeds with login and returns a code .

The client exchanges the code for a long‑lived token following OAuth2.0; the token’s expiry is extended on each request to achieve “never‑offline” behavior.

Extended Database Design

Based on community feedback, the following tables are introduced:

Users (business‑side login table)

Field

Remark

user_id

User ID

token

Login token

expire_in

Token expiration

try_times

Failed login attempts

User Authentication Relation (user_auth_rel)

Field

Remark

id

Auto‑increment ID

user_id

Reference to users

auth_id

Reference to auth table

auth_type

local or third

Local User Auth (user_local_auth)

Field

Remark

auth_id

Auto‑increment ID

user_name

Unique username

password

User password

mobile

User mobile number

Third‑Party User Auth (user_third_auth)

Field

Remark

auth_id

User ID

openid

Third‑party unique identifier

login_type

Platform identifier (qq, wechat, …)

access_token

Token for verification

The design separates self‑built accounts from third‑party accounts, reflecting a natural evolution from a single internal system to a hybrid one.

Conclusion

Third‑party login integration is technically straightforward; adding a user_third_auth table supports many providers, though in practice only a few are needed to keep UI clean.

This simple design does not cover sharding, service‑oriented architecture, or massive scale, but provides a solid foundation for further extensions as user volume grows.