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

1. Self‑Built Login System

1.1 Phone Number Registration

The design assumes each phone number maps to a unique user; the phone number is mandatory.

Process:

Enter phone number → server checks existence. If absent, generate a random verification code, store phone, code in Redis with a typical 5‑minute TTL, then SMS the code.

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

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

Problems:

Poor UX – users must request a code, fill multiple fields, then register.

Forgotten passwords require a reset flow.

1.2 Optimized Registration/Login

The idea is to make the password optional: regardless of prior registration, users can log in with phone + code while still supporting phone + password for existing accounts.

Process:

Enter phone number → server generates a code, stores it in Redis, and SMSes it.

User submits the received code. Server validates it in Redis. If the phone belongs to an existing user, log them in; otherwise, create a new user and allow optional profile completion.

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

User table design (simplified):

id | user_name | user_password | user_mobile | state | more
---|-----------|---------------|------------|-------|------
User ID | Username | Password | Phone number | Account status | Other info

2. Optimized Account System

2.1 Analysis of the Original System

Both native login ( phone + password) and verification‑code login ( phone + code) store user info + password for verification.

Third‑party login also follows the user info + token pattern, where the 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
---|----------|--------|------
User ID | Nickname | Avatar URL | Other info

User authorization info table:

id | user_id | identity_type | identifier | credential
---|---------|---------------|------------|-----------
Primary key | User ID | Login type (e.g., phone, email, WeChat) | Unique identifier (phone, email, openId) | Password or token

Explanation:

The user data is split into a basic info table and an auth table; the latter holds all credential records.

The basic info table never stores passwords or login identifiers.

One user can have many auth records (multiple WeChat accounts, emails, phones), though a limit per type can be enforced.

2.2.2 Login Flow phone + code – reuse the previous scheme. email/phone + password – determine the login type, fetch the corresponding credential from user_auths, compare hashes, then retrieve the user_id and user profile.

Third‑party login (e.g., WeChat): use type='weixin' and identifier='WeChat openId' to locate the auth record; if found, log in directly and update the token.

2.2.3 Pros and Cons

Advantages:

Login types are infinitely extensible; adding a new provider only requires a new auth record.

Verification status can be unified in a single verified field in user_auths, simplifying UI checks.

Tracking timestamps and IPs per auth record enables detailed usage analytics.

Credentials are optional; users may bind multiple accounts of the same type.

Disadvantages:

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

Logic complexity increases, especially when handling edge cases such as an existing third‑party account being linked to a different user or multiple bindings.

3. One‑Click Login

3.1 Background

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

Instead, mobile operators can verify the SIM card directly. By calling the operator’s API after the user inputs a phone number, the backend can confirm that the number belongs to the device, eliminating the need for an SMS code.

3.2 Mobile Number Authentication

Steps:

SDK initialization – provide AppKey and AppSecret.

Invoke the SDK to request a masked phone number from the operator; the SDK shows an authorization page with the masked number and agreement.

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

Send the token to the server; the server calls the operator’s one‑click login API, receives the real phone number, and performs login or registration.

Alibaba Cloud already offers an SDK compatible with the three major carriers.

4. Conclusion

There is no universally best solution; choose the design that fits the current system. The key is to balance extensibility, user experience, and implementation complexity.