Designing a Unified Multi‑Account Login System: Schemas, Flows, and One‑Click Authentication

Most modern apps support third‑party login (WeChat, QQ, Weibo) and need a robust account schema and flow to ensure scalability.

1. Self‑built login system

1.1.1 Mobile number registration

Each mobile number corresponds to a user; the mobile number is mandatory.

Process:

Enter the mobile number and send it to the server. The server checks if the number exists; if not, it generates a random verification code, stores the Redis entry with an expiration (usually 5 minutes), and sends the code via SMS.

The user receives the code, fills in the code and optional password, and submits the data. 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 mobile+password .

Problems:

Poor user experience – users must obtain a verification code, fill many fields, and then register before using the app.

Easy to forget passwords; password recovery is the only way to reset them.

1.1.2 Optimized registration/login

The idea is to make the password optional: users can log in directly with mobile+verification code while still supporting mobile+password login.

Process:

Enter the mobile number; the server generates a random code, stores it in Redis with a short TTL, and sends the code via SMS.

The user inputs the received code and submits. The server validates the code in Redis . If the user already exists, it returns the user info; otherwise it prompts the user to complete optional profile information.

After logging in with mobile+code , the user may set a password, enabling future mobile+password login. Password is therefore non‑mandatory.

User table design:

id

user_name

user_password

user_mobile

state

more

用户id

用户名

用户密码

手机号码

账号状态

其他信息

1.2 Introducing third‑party accounts

1.2.1 Weibo login

The client invokes the Weibo login UI, the user enters Weibo credentials, and a successful login returns an access_token . The server uses the token to call the Weibo API and obtain user information.

The server then creates a local account linked to the Weibo user, allowing future logins via that Weibo account.

Weibo user information table:

id

user_id

uid

access_token

主键id

用户id

微博唯一id

授权码

1.2.2 "Nightmare" scenario

When many providers (QQ, WeChat, NetEase, etc.) need to be integrated, a separate table similar to the Weibo table is created for each, and a new set of login logic is written.

2. Optimizing the account system

2.1 Original account system analysis

Both self‑built login ( mobile+password or mobile+code ) and third‑party login rely on a user info + credential model, where the credential is either a password or an access_token .

Third‑party login also uses the third‑party unique ID as the identifier and the token as a time‑limited password.

2.2 New account system

2.2.1 Data table design

Basic user information table:

id

nickname

avatar

more

用户id

昵称

头像

其他信息

Authorization information table:

id

user_id

identity_type

identifier

credential

主键id

用户id

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

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

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

Explanation:

The user data is split into a basic user info table and an authorization info table.

The basic table stores only nickname, avatar, etc.; all login‑related data (mobile, email, third‑party IDs, passwords, tokens) reside in the authorization table, establishing a one‑to‑many relationship.

2.2.2 Login flow

mobile+code : same as the earlier optimized flow.

For email/phone+password :

The user submits email/phone+password . The server determines the login type (e.g., type='phone' ) and looks up the record by identifier='手机号' . If found, it compares the stored credential (password hash) with the submitted password. On success it retrieves the user_id and loads the user profile.

Third‑party login (e.g., WeChat): the server queries type='weixin' together with identifier='微信 openId' . If a record exists, login succeeds and the token may be updated; otherwise registration or binding logic is applied.

2.2.3 Pros and cons

Advantages:

Login types can be extended indefinitely, reducing development cost for new providers.

Verification status is unified in a single verified field in the authorization table, simplifying checks across all login methods.

Adding timestamps and IP addresses to the authorization table enables detailed usage tracking (e.g., how long a Weibo account has been inactive).

Multiple accounts of the same type can be bound to a single user (multiple WeChat, emails, phones), with optional constraints.

Disadvantages:

If a user has several login methods (email, phone, username), changing the password requires updating all related records, which can lead to inconsistent states.

Logic complexity and code volume increase, especially when handling various edge cases during third‑party binding and login.

3. One‑click login

3.1 Background

The traditional mobile+code flow takes about 20 seconds, depends on SMS delivery, and poses security risks if the code is intercepted.

Carrier‑based verification can directly confirm that the entered number matches the SIM card, eliminating the need for an SMS code.

3.2 Device number authentication

Steps:

SDK initialization – provide AppKey and AppSecret.

Invoke the SDK to open the carrier‑provided 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 the login button; the SDK receives a token from the carrier.

The token is sent to the developer’s server, which calls the carrier’s one‑click login API to obtain the real phone number. The server then creates or logs in the user and returns the result to the client.

Alibaba Cloud currently provides an SDK that supports the three major Chinese carriers (see https://help.aliyun.com/document_detail/121113.html).

4. Summary

There is no universally best solution; choose the design that fits your current system, balance extensibility with complexity, and avoid over‑engineering.