Designing a Multi‑Account Unified Login System and Optimized Authentication Flow

1. Self‑Built Login System

Most modern App s support multiple third‑party logins (WeChat, QQ, Weibo, etc.), which we refer to as unified multi‑account login. The design of account tables and login flows is critical for future extensibility.

1.1.1 Phone Number Registration

The idea is that each phone number corresponds to a user; the phone number is mandatory.

Process:

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

User receives the code, fills it together with a password and other basic info, and submits to the server. The server validates the code in Redis ; on success it 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.

Passwords can be forgotten; recovery requires a separate “forgot password” flow.

1.1.2 Optimized Registration/Login

The approach weakens the password requirement: regardless of whether the user has registered before, they can log in directly with phone+code (while still supporting phone+password login).

Process:

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

User receives the code and only needs to submit the code. The server validates the code in Redis ; on success the user is logged in. New users are prompted to complete optional profile information.

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

User table design:

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 third‑party login via Weibo. After the user logs in on Weibo and obtains an access_token , the server creates a local account linked to the Weibo UID.

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 is created for each provider, leading to duplicated logic.

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 password is the access_token and the user info is the third‑party UID.

2.2 New Account Architecture

2.2.1 Data Table Design

User basic information table:

id

nickname

avatar

more

用户id

昵称

头像

其他信息

User authorization information 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 auth info table.

The basic table stores only display fields (nickname, avatar, etc.). All authentication‑related data (login type, identifier, credential, verification status, timestamps, IP) reside in the auth table, establishing a one‑to‑many relationship.

2.2.2 Login Process

Phone‑code login follows the same flow as before. Email/phone‑password login checks the type='phone' (or type='email' ) and matches the credential against the stored password hash.

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

2.2.3 Pros and Cons

Advantages:

Unlimited extension of login types with reduced development cost.

Unified verified flag in the auth table replaces multiple phone_verified / email_verified columns.

Additional fields such as timestamps and IP enable detailed usage tracking.

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

Disadvantages:

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

Increased code volume and more complex conditional logic for handling various binding scenarios.

3. One‑Click Login

3.1 Background

The traditional phone+code flow requires entering the number, waiting for an SMS, and typing the code, which takes about 20 seconds and depends on network reliability.

Carrier‑based one‑click login can obtain the device’s SIM number directly, eliminating the need for manual input and SMS verification.

3.2 Mobile Number Authentication

Steps:

SDK initialization – provide AppKey and AppSecret.

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

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

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

Alibaba Cloud already offers such a service compatible with the three major carriers (see Alibaba Cloud documentation ).

Overall, the article provides a comprehensive design guide for building a flexible, extensible multi‑account authentication system, covering database schema, flow diagrams, third‑party integration, and modern one‑click login techniques.