A 3‑Year‑Proven Universal Multi‑Account Login Architecture

Self‑built login system

1.1 Phone number login & registration

Each phone number maps to a user; the phone number is mandatory.

Process:

Client submits phone number. Server checks if the number exists. If not, generate a random verification code, bind the phone number and code in Redis with a 5‑minute TTL, and send the code via SMS.

User enters the received code (and optional password). Server validates the code in Redis. On success, create a user account and store the password.

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

Problems:

Poor user experience – waiting for an SMS and filling multiple fields before using the app.

Password forgetting – recovery requires a separate “forgot password” flow.

1.2 Optimized registration/login

Make the password optional; users can log in directly with phone+code while still supporting phone+password as a fallback.

Process:

Client sends phone number; server generates a verification code, stores it in Redis (5‑minute TTL), and sends the code via SMS.

User submits only the code. Server checks the code in Redis. If valid, log in immediately. Existing users are fetched; new users are prompted (non‑mandatory) to complete their profile.

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

User table columns (core fields):

id

user_name

user_password

user_mobile

state

more (additional info)

1.3 Third‑party account integration

1.3.1 Weibo login

Steps:

Client opens the Weibo login UI, enters credentials, and receives an access_token. The token is used to call Weibo’s API and fetch user info.

Server creates a local account linked to the Weibo user ID; thereafter the Weibo account can be used for direct login.

1.3.2 Issue with naïve expansion

When additional providers (QQ, WeChat, NetEase, etc.) are added, copying the Weibo user‑info table and rewriting separate tables and logic for each provider leads to duplication and maintenance overhead.

Optimizing the account system

2.1 Analysis of the original system

Both self‑built and third‑party logins ultimately verify a user info + password pair, where the password is either a stored credential or a time‑limited access_token.

Third‑party login treats the provider’s unique ID as the identifier and the token as a temporary password.

2.2 New account system

2.2.1 Data model

Two tables are introduced:

User basic info : id, nickname, avatar, more.

User auth info : id, user_id (FK to basic info), identity_type (e.g., phone, email, WeChat, Weibo), identifier (phone number, email address, or third‑party UID), credential (stored password or token). The relationship is one‑to‑many: a user can have multiple auth records.

2.2.2 Login flow

phone+code

: reuse the earlier flow. email/phone+password: client sends type='phone' (or type='email') and identifier='the phone or email'. Server looks up the corresponding credential, compares it with the submitted password hash, and on match retrieves the user_id to fetch user info.

Third‑party login (e.g., WeChat): client sends type='weixin' and identifier='WeChat openId'. If a record exists, log in directly and optionally update the stored token.

2.2.3 Advantages

Login types can be extended without code changes; adding a new provider only requires inserting a new auth record.

Verification status is unified in a single verified field inside user_auths, eliminating per‑method flags like phone_verified or email_verified.

Storing timestamps and IP addresses in user_auths enables tracking of usage patterns (e.g., Weibo unused for two years, WeChat bound for 300 days).

Basic user table holds only display‑oriented fields (nickname, avatar, etc.); authentication data lives exclusively in the auth table, keeping concerns separated.

Multiple accounts of the same type can be bound to a single user (multiple WeChat, emails, or phones), with the option to enforce a one‑record limit per type.

2.2.4 Disadvantages

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

Code complexity grows: the login handler must branch on type, handle registration‑vs‑binding scenarios, and resolve conflicts when a third‑party account is already linked to another user.

Edge cases include:

Third‑party account not yet registered – create and log in.

Third‑party account exists, user not logged in – log in directly.

Third‑party account exists, user logged in, but bound to a different third‑party – decide whether to allow multiple bindings.

Third‑party account exists and user already logged in with the same account – avoid duplicate binding.

One‑click login

3.1 Background

The traditional phone+code flow requires entering the phone number, waiting for an SMS, typing the code, and clicking login, often taking 20 seconds and depending on network reliability. It also carries the risk of code leakage.

3.2 Mobile number authentication

Instead of sending an SMS, the operator can verify the SIM card directly. After the user inputs a phone number, the app calls the operator’s API to confirm that the number matches the device’s SIM. This removes the SMS step and shortens the flow to about 2 seconds. When the operator returns the actual phone number, the user no longer needs to type it, enabling true “one‑click” login.

Key steps:

SDK initialization – invoke the SDK with the project’s AppKey and AppSecret.

Invoke the authorization page – the SDK requests a masked number from the operator, then shows the mask and the operator agreement to the user.

User consents and clicks login – the SDK obtains a token representing the number request.

Server side – the token is sent to the backend, which calls the operator’s one‑click login API, receives the real phone number, and performs login or registration.

Alibaba Cloud currently provides an SDK that supports the three major Chinese carriers.

Summary

The appropriate design depends on the existing system and business needs. Choose the scheme that fits the architecture, balances extensibility, user experience, and security, and avoid over‑optimizing for a single metric.