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

Most modern apps support multiple third‑party logins (WeChat, QQ, Weibo) and we refer to this as unified multi‑account login; the design of account tables and processes is critical for future scalability.

1. Self‑built login system

1.1.1 Mobile number login & registration

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

Process:

Enter mobile number, send to server. If the number does not exist, generate a random verification code, bind the number and code to Redis with an expiration (typically 5 minutes), then send the code via SMS.

User receives the code, fills in the code and basic info (e.g., password), and submits to the server. The server checks the code in Redis ; if it matches, a user account is created and the password is stored.

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

Issues:

Poor user experience – users must obtain a code, fill in multiple fields before they can use the app.

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

1.1.2 Optimized registration/login

We weaken the requirement for a password: regardless of whether the user has previously registered, they can log in directly with mobile number + verification code while still supporting mobile number + password as an optional method.

Process:

Enter mobile number, send to server. The server generates a random verification code, binds the number and code to Redis with a 5‑minute expiration, and sends the code via SMS.

User receives the code and only needs to input the code on the UI; the server validates the code in Redis . If valid, the user is logged in. New users are prompted to optionally complete their profile.

After logging in with mobile number + verification code , the user may set a password, enabling future mobile number + password login; the password is not 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

Process:

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

The server creates an account in our user table based on the fetched information; thereafter the user can log in directly with the Weibo account.

Weibo user info table design:

id

user_id

uid

access_token

主键id

用户id

微博唯一id

授权码

1.2.2 Nightmare arrives

Subsequently, QQ, WeChat, NetEase and other platforms opened login APIs, forcing us to create separate tables for each third‑party and rewrite integration logic for each.

2. Optimizing the account system

2.1 Analysis of the original system

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

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

2.2 New account system

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 information table and a user authorization information table .

The basic table stores only non‑credential fields such as nickname and avatar; all login‑related credentials (passwords, tokens, identifiers) reside in the authorization table, which has a one‑to‑many relationship with the basic table.

2.2.2 Login flow

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

For email/phone + password login, the server first determines the login type (e.g., type='phone' ) and queries the authorization table using identifier='mobile number' . If a matching record is found, the stored credential (password hash) is compared; on success the user_id is used to fetch the user’s basic profile.

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

2.2.3 Pros and cons

Advantages:

Login types can be extended indefinitely with low development cost.

A single verified field in the authorization table indicates verification status for any login method.

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

Multiple bindings per user are possible (e.g., several WeChat accounts, multiple emails), with optional constraints.

Disadvantages:

When a user has several login methods, changing a password must be done for each, leading to inconsistent states.

More code and conditional logic increase complexity, especially handling edge cases where a third‑party account is already linked to another user.

3. One‑click login

3.1 Background

Review of the traditional mobile+code flow reveals drawbacks: lengthy steps, reliance on SMS delivery, and security risks from code leakage.

Instead of SMS, carriers can provide direct SIM‑card data to verify the phone number, eliminating the need for a verification code.

3.2 Native number authentication

By obtaining the device’s current SIM number, the app can log in directly. This reduces the login time from around 20 seconds to about 2 seconds and removes SMS dependency.

Main steps:

SDK initialization – call the SDK’s init method with the project’s AppKey and AppSecret.

Invoke the authorization page – the SDK requests a carrier‑provided token, then displays a masked phone number and the carrier agreement for user confirmation.

User consents and clicks login – the SDK receives the token and returns it to the client.

Number retrieval – the client sends the token to our server, which calls the carrier’s one‑click login API to obtain the phone number, then performs login or registration based on that number.

Alibaba Cloud currently offers an SDK compatible with the three major carriers (see https://help.aliyun.com/document_detail/121113.html).

4. Summary

There is no universally best solution; choose the design that fits the current system, avoid over‑engineering, and ensure the chosen method aligns with user experience and security requirements.

© Content sourced from the internet; original author retains copyright.