Designing a Multi‑Account Unified Login System: From Phone Number Authentication to Third‑Party Integration

1. Self‑Built Login System

1.1.1 Phone Number Login & Registration

The design assumes each phone number maps to a unique user and is mandatory. The flow is:

Enter phone number, send to server; if the number does not exist, generate a random verification code, store the Redis entry with a short TTL (typically 5 minutes), and send the code via SMS.

User receives the code, submits it together with basic info; the server validates the code in Redis , creates a user account and saves the password.

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

Problems:

Poor user experience – users must obtain a code, fill many fields, then register.

Forgotten passwords require a reset flow.

1.1.2 Optimized Registration/Login

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

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

User submits the received code; the server validates it in Redis . If validation succeeds, the user is logged in. Existing users have their profile fetched; new users are prompted (non‑mandatory) to complete additional information.

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

User table design (illustrated in the original image) separates basic user info from authentication data.

1.2 Introducing Third‑Party Accounts

1.2.1 Weibo Login

Client invokes the Weibo login UI; after entering credentials, Weibo returns an access_token . The server uses this token to call the Weibo API, fetches user information, and creates a corresponding account in the local user table.

Weibo user information table design is shown in the accompanying diagram.

1.2.2 The Nightmare of Multiple Providers

When QQ, WeChat, NetEase, etc., open login APIs, the system must replicate the Weibo‑style tables and logic for each provider, leading to duplicated schemas and complex integration.

2. Optimizing the Account System

2.1 Analysis of the Original System

Self‑built login uses either phone+password or phone+code , both relying on a combined user info + password verification.

Third‑party login also follows a user info + password model, where the “password” is the provider’s access_token (a time‑limited credential).

2.2 New Account System

2.2.1 Data Table Design

Two tables are introduced:

User Basic Information Table – stores only non‑sensitive data such as nickname, avatar, etc.

User Authorization Information Table – stores all authentication‑related data (phone, email, third‑party IDs, tokens, verification status). This table has a one‑to‑many relationship with the basic info table.

Advantages include eliminating password storage in the basic table, centralising verification flags, and simplifying the addition of new login methods.

2.2.2 Login Flow

Phone + verification code – same as before.

Email/Phone + password – the server receives type='phone' (or type='email' ) and identifier='value' , looks up the corresponding password_hash , compares it with credential , and on success retrieves the user_id to fetch user details.

Third‑party login (e.g., WeChat): query type='weixin' with identifier='WeChat openId' . If a record exists, login succeeds and the token is refreshed; no additional credential check is needed assuming the carrier communication is secure.

2.2.3 Pros & Cons

Pros

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

Unified verification flag ( verified ) in the authorization table replaces multiple phone_verified / email_verified columns.

Ability to track login timestamps and IP addresses per provider for better user‑behavior analytics.

Supports binding multiple accounts of the same type (e.g., multiple WeChat accounts) or restricting to a single record per type.

Cons

When a user has several login methods (email, username, phone), password changes must be synchronised across all, otherwise inconsistent login states arise.

Increased code complexity and branching logic, especially when handling edge cases such as a third‑party account existing but the current user is logged in with a different provider.

3. One‑Click Login

3.1 Background

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

3.2 Device Number Authentication

One‑click login leverages carrier‑provided APIs to obtain the device’s SIM number directly, eliminating the need for user‑entered verification codes.

SDK initialization – provide the project’s AppKey and AppSecret.

Invoke the SDK to display the carrier‑provided authorization page, which shows a masked phone number and the carrier agreement.

User consents and clicks the login button; the SDK returns a token representing the number‑retrieval request.

The token is sent to the backend, which calls the carrier’s one‑click login API to obtain the actual phone number, then performs login or registration based on that number.

This reduces the login time to roughly 2 seconds and improves user experience.

--- End of article ---