Designing a Multi‑Account Unified Login System and Optimized Account Architecture

Most modern apps support login via multiple third‑party accounts (WeChat, QQ, Weibo, etc.), which we refer to as unified multi‑account login. The design of account tables and login flows is crucial for future extensibility.

1. Self‑Built Login System

1.1.1 Phone Number Registration

The idea is that each phone number corresponds to a user; the phone number is mandatory.

Process:

Enter the phone number, send it to the server. The server checks if the number exists; if not, it generates a random verification code, stores the phone number and code in Redis with an expiration (usually 5 minutes), and sends the code via SMS.

The user receives the code, fills in the code and basic information (e.g., password), and submits to the server. The server verifies the code in Redis ; if it matches, an account is created and the password is saved.

After successful registration, the user can log in with phone number + password .

Problems:

Poor user experience – users must obtain a verification code, fill many fields, and then register before they can use the app.

Passwords can be forgotten; recovery requires a password‑reset flow.

1.1.2 Optimized Registration/Login

The approach weakens the requirement of a password: regardless of whether the user has registered before, they can log in directly with phone number + verification code (while still supporting phone number + password login).

Process:

Enter phone number, send to server. The server generates a verification code, stores it in Redis with a short TTL, and sends the code via SMS.

User receives the code and only needs to input the code. The server checks the code in Redis ; if it matches, the user is logged in. New users are prompted to complete optional profile information.

After logging in with phone number + verification code , the user may optionally set a password, enabling future phone number + password login.

User table design:

id

user_name

user_password

user_mobile

state

more

User ID

Username

Password

Mobile number

Account status

Other info

1.2 Introducing Third‑Party Account Solutions

1.2.1 Weibo Login

In the Web2.0 era, Weibo opened third‑party login. The product requires the ability to log in to the app using a Weibo account and associate it with the internal user table.

Process:

The client invokes the Weibo login UI; after successful authentication, Weibo returns an access_token , which is used to call the Weibo API and fetch user information.

The server creates an internal account based on the fetched user info; thereafter the Weibo account can be used for direct login.

Weibo user info table:

id

user_id

uid

access_token

Primary key ID

User ID

Weibo unique UID

Authorization token

1.2.2 The Nightmare Arrives

Soon QQ, WeChat, NetEase, and many other platforms opened login, requiring the integration of numerous third‑party logins. The solution is to create a new table similar to the Weibo user table and rewrite the integration for each provider.

2. Optimizing the Account System

2.1 Analysis of the Original Account System

Self‑built login: both phone+password and phone+verification code are forms of user info + password verification.

Third‑party login: also user info + password , where the user info is the third‑party ID and the password is the access_token (a time‑limited credential).

2.2 New Account System

2.2.1 Data Table Design

User basic information table:

id

nickname

avatar

more

User ID

Nickname

Avatar URL

Other info

User authorization information table:

id

user_id

identity_type

identifier

credential

Primary key ID

User ID

Login type (phone/email) or third‑party app name (WeChat/Weibo, etc.)

Phone/email/third‑party unique identifier

Password credential (stored password for native accounts, token for third‑party accounts)

Explanation:

The user data is split into User Basic Info + User Authorization Info .

The basic info table does not store any password or login credentials; all authentication‑related data resides in the authorization table, which has a one‑to‑many relationship with the basic info.

2.2.2 Login Flow

phone+verification code – same as the previous scheme.

For email/phone + password login:

The client sends type='phone' together with identifier='phone number' . The server looks up the corresponding record, compares the stored password_hash (or token) with the provided credential, and if they match, retrieves the user_id and returns the user profile.

Third‑party login (e.g., WeChat): the server queries type='weixin' and identifier='WeChat openId' . If a record exists, login succeeds and the token may be refreshed; otherwise a new association is created.

2.2.3 Pros and Cons

Advantages:

Login types can be extended indefinitely with low development cost.

Verification status (phone_verified, email_verified) can be unified into a single verified field in the authorization table.

Adding timestamps and IP addresses to the authorization table enables detailed usage tracking (e.g., how long a user has used a specific third‑party login).

Multiple accounts of the same type can be bound to a single user (multiple WeChat, emails, or phones), or constraints can be applied as needed.

Disadvantages:

If a user has several login methods, changing the password requires updating all of them, leading to confusing situations where different credentials still work.

Code complexity increases; handling various edge cases (e.g., a Weibo account not yet registered, a logged‑in user trying to bind another Weibo account, etc.) adds branching logic.

3. One‑Click Login

3.1 Background

Reviewing the phone+verification code flow reveals drawbacks: it takes ~20 seconds, depends on SMS delivery, and poses security risks if the code is intercepted.

Instead of sending an SMS, the carrier can verify the entered number against the SIM card, or even return the current phone number directly, eliminating the need for user input.

3.2 Mobile Number Authentication

One‑click login obtains the device’s current SIM number and uses it for authentication, reducing the login process to a few seconds.

3.3 Implementation Steps

SDK initialization: call the SDK’s init method with the project’s AppKey and AppSecret.

Invoke the authorization page: the SDK requests a mobile number token from the carrier, then displays a masked number and the carrier’s agreement for user confirmation.

User consents and clicks login: the SDK receives a token representing the phone number.

Server side: send the token to the backend, which calls the carrier’s one‑click login API to retrieve the actual phone number, then perform login or registration based on that number.

Alibaba Cloud provides such a one‑click login SDK compatible with the three major carriers (see https://help.aliyun.com/document_detail/121113.html).

Finally, the author offers a collection of interview questions from major tech companies (BAT) for readers who are interested.