Designing a Scalable Multi‑Account Login System: Phone Verification to One‑Click Auth

Most modern apps support login via multiple third‑party accounts (WeChat, QQ, Weibo, etc.), known as unified multi‑account login. Proper account table and workflow design are crucial for future extensibility.

1. Custom Login System

Phone Number Registration

The design assumes each phone number maps to a single user; the phone number is mandatory.

Process:

Enter phone number, send to server. If the number does not exist, generate a random verification code, bind the phone number and code in Redis with an expiration (typically 5 minutes), then send the code via SMS.

User receives the code, submits it together with a password and other basic info. The server checks the code in Redis; on success, creates an account and stores the password.

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

Problems:

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

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

Optimized Registration/Login

This approach weakens the password requirement: regardless of prior registration, users can log in directly with phone+code (while still supporting phone+password).

Process:

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

User submits the received code only. The server validates the code in Redis. If validation succeeds, the user is logged in; existing users receive their profile, new users are prompted (optionally) to complete additional information.

After logging in with phone+code, the user may set a password, enabling future phone+password login. Password is thus optional.

Third‑Party Account Integration

Weibo Login

Weibo provides an access_token after the user logs in on its site. The server uses this token to call the Weibo API and retrieve user information, then creates a corresponding account in the local user table.

Process:

Client invokes Weibo login UI, user enters credentials, and Weibo returns an access_token. The token is used to fetch user data via the Weibo API.

The server creates a local account linked to the Weibo user ID, enabling future login with the Weibo account.

When additional providers (QQ, WeChat, NetEase, etc.) are added, a separate table similar to the Weibo user info table is created for each provider.

2. Optimized Account System

Analysis of the Original System

Both native login ( phone+password or phone+code) and third‑party login rely on a “user info + credential” model, where the credential is either a password or an access_token.

Third‑party credentials are essentially time‑limited passwords tied to the provider’s unique ID.

New Account Architecture

Database Design

User Base Table

id

nickname

avatar

more

User ID

Nickname

Avatar URL

Other info

User Authorization Table

id

user_id

identity_type

identifier

credential

Primary key

User ID

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

Phone, email, or third‑party unique identifier

Password or token stored for the credential

Explanation:

The user data is split into a base table and an authorization table.

The base table stores only non‑credential information (nickname, avatar, etc.). All login‑related data resides in the authorization table, which has a one‑to‑many relationship with the base table.

Login Flow phone+code – same as described earlier.

For email/phone+password login:

The client sends type='phone' together with identifier='phone number'. The server looks up the matching record, compares password_hash with the stored credential, and on success retrieves the associated user_id to fetch the user profile.

Third‑party login (e.g., WeChat): query type='weixin' with identifier='WeChat openId'. If a record exists, login succeeds and the server may update the token. This assumes a trusted channel with the provider.

Advantages

Unlimited login types; adding a new provider incurs minimal development effort.

A single verified flag in the authorization table replaces multiple per‑field verification columns (e.g., phone_verified, email_verified).

Storing timestamps and IP addresses in the authorization table enables detailed usage tracking.

Credentials become display‑only fields in the base table; they are no longer core user attributes.

Multiple accounts of the same type can be bound to a single user (e.g., several WeChat IDs), with optional constraints.

Disadvantages

When a user has several login methods, password changes must be synchronized across all, otherwise inconsistent login states arise.

Increased code complexity and branching logic, especially when handling edge cases such as binding an already‑registered third‑party account to a logged‑in user.

3. One‑Click Login

Background

The traditional phone+code flow requires entering the number, waiting for an SMS, typing the code, and clicking login, which can take 20 seconds and depends on network reliability. It also poses security risks if the code is intercepted.

Carrier‑based one‑click login eliminates the need for SMS verification by directly obtaining the device’s phone number from the operator.

Main Steps

SDK initialization: provide AppKey and AppSecret.

Invoke the SDK to display the authorization page; the SDK requests the carrier for a phone‑number token and shows a masked number with the carrier agreement.

User consents and clicks login; the SDK returns a token.

The token is sent to the server, which calls the carrier’s one‑click API to retrieve the actual phone number, then logs in or registers the user accordingly.

Alibaba Cloud currently offers an SDK compatible with the three major Chinese carriers (see

https://help.aliyun.com/document_detail/121113.html

).

4. Summary

There is no universally best solution; choose the design that fits your system’s needs. The key is to keep the architecture extensible, maintain a clear separation between user profile data and authentication credentials, and support easy addition of new login methods.