Designing a Scalable Multi‑Account Login System: From Phone Verification to Third‑Party OAuth

Introduction

Most apps now support multiple third‑party accounts (WeChat, QQ, Weibo, etc.). The article discusses the importance of a well‑designed account table and login flow to ensure good extensibility.

1. Self‑built Login System

1.1.1 Phone number registration

Each phone number maps to a user; the phone number is mandatory.

Process

Enter phone number, send to server. Server checks if the number exists; if not, generates a random verification code, stores it in Redis with a 5‑minute TTL, and sends the code via SMS.

User receives the code, fills it together with password and basic info, sends to server. Server validates the code from Redis. On success, creates a user account and saves the password.

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

Problems

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

Easy to forget passwords; password recovery is required.

1.1.2 Optimized registration/login

The password field is made optional. Users can log in directly with phone+code while still supporting phone+password for legacy accounts.

Process

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

User enters the received code only; server validates the code in Redis. If the user already exists, their profile is returned; otherwise the user is prompted to complete optional profile information.

After logging in with phone+code, the user may set a password, making phone+password a non‑mandatory login method.

User table design (simplified):

id – user identifier

user_name – username

user_password – password (may be empty)

user_mobile – phone number

state – account status

more – additional info

2. Third‑party Account Integration

2.1 Weibo login

Weibo provides an access_token after the user logs in on the Weibo page. The server uses the token to call Weibo’s API, obtains user information, and creates a corresponding account in the local user table.

Weibo user table (simplified):

id – primary key

user_id – local user id

uid – Weibo unique id

access_token – authorization token

2.2 “Nightmare” – multiple third‑party providers

When QQ, WeChat, NetEase, etc. are added, a new table similar to the Weibo table is created for each provider, and separate integration code is written.

3. Optimized Account System

3.1 Analysis of the original system

Both native login ( phone+password or phone+code) and third‑party login rely on “user info + credential” verification.

Third‑party login uses the third‑party ID as the identifier and the access_token as a temporary password.

3.2 New account architecture

3.2.1 Table design

User basic information table:

id – user id

nickname – display name

avatar – profile picture

more – other fields

User authorization information table:

id – primary key

user_id – reference to basic info

identity_type – login type (phone, email, WeChat, Weibo, etc.)

identifier – phone, email, or third‑party unique id

credential – stored password or third‑party token

Key points:

The system separates basic profile from authentication data; a user can have many authorization records (one‑to‑many).

No password is stored in the basic user table.

Verification status can be tracked with a unified verified field in the auth table.

Additional metadata such as binding time and IP can be added to the auth table.

3.2.2 Login flow

phone+code

– same as before. email/phone+password – server checks type='phone' or type='email', looks up the identifier, compares the stored credential (password hash) and logs in.

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

3.2.3 Pros and cons

Advantages

Unlimited login type expansion; adding a new provider only requires a new auth record.

Verification status is centralized in the auth table.

Binding multiple accounts of the same type is possible.

Disadvantages

When a user has several internal login methods, password changes must be synchronized across all methods.

More code and conditional logic increase complexity.

4. One‑Click Login

4.1 Background

Traditional phone+code requires entering the number, waiting for an SMS, and typing the code, which takes about 20 seconds and depends on network availability.

4.2 Mobile number auto‑verification

Operators can provide the device’s SIM number directly. By calling the operator’s API after the user inputs the phone number, the backend can verify that the entered number matches the device’s number, eliminating the SMS step.

4.3 One‑click login flow

SDK initialization with AppKey and AppSecret.

Invoke SDK to open the authorization page; the SDK requests a token from the operator.

User consents, SDK receives the token.

Server exchanges the token for the real phone number, then logs in or registers the user.

Alibaba Cloud provides an SDK that supports the three major Chinese carriers.

5. Conclusion

There is no universally best solution; choose the design that fits the current system’s requirements and constraints.