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

1. Self‑Built Login System

1.1.1 Phone Number Login Registration

The design assumes each phone number corresponds to a user, with the phone number being 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), and send the code via SMS.

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

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

Problems:

Poor user experience – users must obtain a verification code, fill multiple fields, and then register.

Passwords can be forgotten, requiring a reset flow.

1.1.2 Optimized Registration/Login

This approach weakens the password requirement: users can log in directly with phone number + verification code, while still supporting phone number + password login.

Process:

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

User enters the received code; the server validates it against Redis. If valid, the user is logged in. Existing users have their profile fetched; new users are prompted to complete optional profile information.

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

1.2 Introducing Third‑Party Account Solutions

1.2.1 Weibo Login

The client invokes the Weibo login UI, the user enters credentials, and upon success an access_token is returned. The server uses the token to call the Weibo API, retrieves user information, and creates a corresponding account in the local user table.

Weibo user table design includes fields: id, user_id, uid, access_token.

1.2.2 Adding More Third‑Party Providers

Subsequent integrations (QQ, WeChat, NetEase, etc.) require similar tables and logic, leading to a unified approach based on the Weibo user table.

2. Optimizing the Account System

2.1 Analysis of the Original Account System

Self‑built login uses phone number + password or phone number + verification code, both verifying user info + password.

Third‑party login also verifies user info + password, where the password is the access_token that expires periodically.

2.2 New Account System

2.2.1 Data Table Design

Two tables are introduced:

User Basic Info : id, nickname, avatar, more.

User Authorization Info : id, user_id, identity_type (phone/email/third‑party name), identifier (phone/email/third‑party unique ID), credential (password or token).

The user basic table stores only non‑credential data (nickname, avatar, etc.). The authorization table holds all login methods and a verified flag, allowing flexible binding of multiple accounts.

2.2.2 Login Flow

For phone number + verification code, the existing flow is retained.

For email/phone + password, the server determines the login type, retrieves the corresponding record, compares the stored credential with the supplied password hash, and logs the user in using user_id.

Third‑party login (e.g., WeChat) queries the authorization table with type='weixin' and identifier='WeChat openId'. If a record exists, login succeeds and the token may be updated.

2.2.3 Advantages and Disadvantages

Advantages:

Unlimited login type expansion with reduced development cost.

A single verified field in the authorization table replaces multiple phone_verified and email_verified columns.

Additional metadata (timestamp, IP) can be stored for each authorization record, enabling detailed usage tracking.

Multiple accounts of the same type can be bound to a single user, or constrained to one per type.

Disadvantages:

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

Increased code complexity and more conditional logic.

3. One‑Click Login

3.1 Background

Traditional phone number + verification code login requires entering the number, waiting for an SMS, and typing the code, which can take over 20 seconds and depends on network reliability.

3.2 Device Number Authentication

By obtaining the device’s SIM number via carrier APIs, the app can verify the entered number against the actual device number, eliminating the need for an SMS. Some carriers even return the number directly, enabling true one‑click login.

Steps:

Initialize the SDK with the app’s AppKey and AppSecret.

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

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

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

Alibaba Cloud currently provides an SDK compatible with the three major carriers.

4. Summary

The author suggests choosing the design that best fits the current system; there is no universally optimal solution.