Designing a Multi‑Account Unified Login System: Schemas, Flows, and Optimizations

1. Self‑built Login System

1.1.1 Phone Number Login & Registration

The design assumes each phone number corresponds to a unique user and the phone number is mandatory.

Process:

Enter the phone number, send it to the server, generate a random verification code, store the phone+code pair in Redis with a typical 5‑minute expiration, and send the code via SMS.

User receives the code, fills in the code and basic information (e.g., password), and submits to the server. The server verifies the code in Redis ; on success it creates a user account and stores the password.

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

Problems:

Poor user experience – users must obtain a code, fill many fields, and then log in.

Forgotten passwords require a reset flow.

1.1.2 Optimized Registration & Login

The idea is to make the password optional: users can log in directly with phone+code while still supporting phone+password for those who set a password.

Process:

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

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

After a successful phone+code login, the user may optionally set a password, enabling future phone+password logins.

User Table Design (original):

id

user_name

user_password

user_mobile

state

more

用户id

用户名

用户密码

手机号码

账号状态

其他信息

1.2 Introducing Third‑Party Account Schemes

1.2.1 Weibo Login

The Web2.0 era opened Weibo as a third‑party login provider. The flow is:

Client invokes Weibo login UI, user enters Weibo credentials, and receives an access_token . The token is used to call the Weibo API and fetch user information.

The server creates a local user record linked to the Weibo uid and stores the access_token for future authentication.

Weibo User Info Table:

id

user_id

uid

access_token

主键id

用户id

微博唯一id

授权码

1.2.2 The Nightmare of Multiple Providers

When QQ, WeChat, NetEase, etc., also open login, a new table similar to the Weibo table must be created for each provider, leading to a proliferation of login implementations.

2. Optimizing the Account System

2.1 Analysis of the Original System

Self‑built login treats both phone+password and phone+code as "user info + password" verification.

Third‑party login also follows the "user info + password" model, where the third‑party unique ID acts as the username and the access_token acts as a time‑limited password.

2.2 New Account System

2.2.1 Data Table Design

User Basic Info Table

id

nickname

avatar

more

用户id

昵称

头像

其他信息

User Authorization Info Table

id

user_id

identity_type

identifier

credential

主键id

用户id

登录类型(手机号/邮箱) 或第三方应用名称 (微信/微博等)

手机号/邮箱/第三方的唯一标识

密码凭证 (自建账号的保存密码, 第三方的保存 token)

Explanation:

The user data is split into a User Basic Info table and a User Authorization Info table.

The basic table stores only display‑oriented fields (nickname, avatar, etc.). All authentication‑related data lives in the authorization table, which has a one‑to‑many relationship with the basic table.

2.2.2 Login Flow

phone+code – same flow as described in section 1.1.2.

email/phone+password – client sends type='phone' (or type='email' ) and identifier='the phone or email' . The server looks up the corresponding credential (password hash) and verifies it before retrieving the user_id and user profile.

Third‑party login (e.g., WeChat): query type='weixin' with identifier='WeChat openId' . If a record exists, login succeeds and the token may be refreshed; otherwise a new binding/registration flow is triggered.

2.2.3 Pros & Cons

Advantages:

Login types can be extended indefinitely with low development cost.

Verification status is unified in a single verified field in the authorization table, eliminating the need for separate phone_verified and email_verified columns.

Adding timestamps and IP addresses to the authorization table enables detailed usage tracking (e.g., how long a user has been bound to a specific provider).

Basic user table remains unchanged; email and phone are treated as display attributes rather than core credentials.

Multiple accounts of the same type can be bound to a single user (e.g., several WeChat accounts), or constraints can be added to limit one record per type.

Disadvantages:

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

Code complexity increases; additional branching logic is required to handle various registration and binding scenarios.

3. One‑Click Login

3.1 Background

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

One‑click login leverages carrier APIs to verify the phone number directly, eliminating the SMS step.

3.2 Device Number Authentication

The process:

SDK initialization – provide AppKey and AppSecret.

Invoke the SDK to open the authorization page; the SDK requests a verification token from the carrier and displays a masked phone number with the carrier agreement.

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

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

Alibaba Cloud currently provides an SDK that supports the three major Chinese carriers (see Alibaba Cloud One‑Click Login Documentation ).

Finally, the article includes a promotional note about a "BAT" interview question collection and several unrelated advertisement links, which are not part of the technical content.