A 3‑Year‑Tested Unified Multi‑Account Login Architecture

Self‑Built Login System

Phone‑Number Login & Registration

Each phone number corresponds to a unique user; the phone number is mandatory.

Process:

Enter phone number and send to the server. The server checks whether the number already has an account. If not, it generates a random verification code, stores the Redis entry with a 5‑minute TTL, and sends the code via SMS.

User receives the code, submits the code together with a password and basic profile data. The server validates the code in Redis. On success, an account is created and the password is saved.

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

Problems:

Poor user experience – many fields and steps are required before the account can be used.

Forgotten passwords force users into a reset flow.

Optimized Registration/Login

The password field is optional; any user can log in with phone+code, while phone+password remains supported.

Process:

Enter phone number; the server generates a verification code, stores it in Redis, and sends the SMS.

User submits the received code; the server checks Redis. If the code matches, the user logs in directly. Existing users are fetched; new users are prompted to optionally complete their profile.

After a phone+code login, the user may set a password and later log in with phone+password.

Third‑Party Account Integration

Weibo Login

Client invokes the Weibo login UI; the user enters Weibo credentials. On success Weibo returns an access_token. The server uses this token to call the Weibo API, obtains user information, and creates a linked account in the internal user table.

Scaling to Additional Providers

When providers such as QQ, WeChat, NetEase open login, a new table similar to the Weibo user‑info table is created and a separate integration layer is written for each provider.

Optimized Account Architecture

Analysis of the Original System

Both phone+password and phone+code store user info+password for verification.

Third‑party login also stores user info+password, where the “password” is the access_token (a time‑limited credential).

New Table Design

The user base table holds immutable profile fields (nickname, avatar, etc.). The user authorization table stores each login method (phone, email, WeChat, etc.) together with its credential and a unified verified flag.

Relationship: one user base record ↔ many authorization records.

Illustrations:

Login Flow

phone+code

– same flow as described in the optimized registration section. email/phone+password – server determines the login type (e.g., type='phone'), looks up the record, fetches password_hash, compares it with the stored credential, and on success retrieves user_id to load user information.

Third‑party login (e.g., WeChat): query type='weixin' with identifier='WeChat openId'. If a record exists, log in directly and update the stored token.

Advantages

Login types can be extended indefinitely; adding a new provider incurs minimal development effort.

A single verified flag in the auth table replaces multiple phone_verified and email_verified fields.

The auth table can store verification timestamps and IP addresses, enabling richer usage analytics (e.g., a user has not used Weibo login for two years but has been bound to WeChat for 300 days).

Credentials are optional; a user may bind multiple accounts of the same type (multiple WeChat IDs, emails, or phone numbers) or restrict to one per type.

Disadvantages

When a user possesses several login methods, changing the password must be synchronized across all methods; otherwise inconsistent login states appear (e.g., email+new password works while phone+old password still logs in).

Code complexity grows. Additional branching logic is required to handle various binding scenarios, such as:

Weibo account not yet registered – create and log in.

Weibo account already exists, user not logged in – log in directly.

Weibo account exists, user logged in with a different Weibo – decide whether to allow multiple bindings.

Weibo account already bound to another user – define conflict resolution.

One‑Click Login

Background

The traditional phone+code flow takes more than 20 seconds, depends on SMS delivery, and carries the risk of code leakage.

Carrier‑based one‑click login can verify the SIM number directly, eliminating the need for the user to input a phone number or receive an SMS.

Implementation Steps

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

Invoke the SDK to display the carrier’s authorization page. The SDK first requests a verification token from the carrier; on success it shows a masked phone number and the carrier’s agreement.

User consents and clicks the login button; the SDK obtains a token for the current number.

The token is sent to the backend, which calls the carrier’s one‑click login API, receives the phone number, and then logs in or registers the user accordingly.