Designing a Unified Multi‑Account Login System with Phone, Password, and Third‑Party Authentication

1. Self‑Built Login System

1.1.1 Phone Number Registration/Login

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

Process:

Enter phone number, send to server. If the number does not exist, generate a random verification code, bind the phone number and code in Redis with a typical 5‑minute expiry, then send the code via SMS.

User receives the code, fills in the code plus basic info (e.g., password) and submits to the server. The server checks the code stored in Redis ; on success it creates a user account and stores the password.

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

Problems:

Poor user experience – users must obtain a verification code, fill many fields, and then can use the app.

Passwords can be forgotten; recovery requires a separate reset flow.

1.1.2 Optimized Registration/Login

The idea is to make the password optional: users can log in directly with phone number + verification code while still supporting the traditional phone number + password method.

Process:

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

User submits the received code; the server validates it in Redis . If valid, the user is logged in. New users are prompted (non‑mandatory) to complete their profile.

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

User table design:

id

user_name

user_password

user_mobile

state

more

User ID

Username

Password

Mobile number

Account status

Other info

1.2 Introducing Third‑Party Account Solutions

1.2.1 Weibo Login

In the Web2.0 era, Weibo opened third‑party login. The product team decided to allow users to log in to the app using a Weibo account, linking it to our own user table.

Process:

The client invokes the Weibo login UI; after entering credentials, Weibo returns an access_token . The token is used to call the Weibo API and fetch user information.

The server creates a user record based on the fetched information, enabling future logins via the Weibo account.

Weibo user info table design:

id

user_id

uid

access_token

Primary key

User ID

Weibo unique UID

Authorization token

1.2.2 The Nightmare Begins

Soon QQ, WeChat, NetEase, and many other providers opened login APIs. To accommodate them, a new table similar to the Weibo table is created for each provider, leading to duplicated schemas.

2. Optimizing the Account System

2.1 Analysis of the Original System

Both self‑built login ( phone+password or phone+code ) and third‑party login ultimately verify a user info + credential pair, where the credential is either a password or an access_token .

Third‑party login also relies on a unique identifier (ID) from the external system and a time‑limited credential (token).

2.2 New Account System

2.2.1 Data Table Design

User basic information table:

id

nickname

avatar

more

User ID

Nickname

Avatar URL

Other info

User authorization information table:

id

user_id

identity_type

identifier

credential

Primary key

User ID

Login type (phone/email) or third‑party name (WeChat/Weibo, etc.)

Phone / email / third‑party unique ID

Password hash or third‑party token

Key points:

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

The basic table stores no passwords or login identifiers; all authentication data resides in the authorization table, establishing a one‑to‑many relationship.

2.2.2 Login Flow

phone+code – same flow as described earlier.

For email/phone + password :

Client sends type='phone' (or type='email' ) and the identifier. The server looks up the corresponding record in the authorization table, verifies the stored password_hash against the submitted credential, and retrieves the associated user_id to fetch user details.

Third‑party login (e.g., WeChat):

Query the authorization table with type='weixin' and the WeChat openId . If a record exists, login succeeds and the token may be refreshed.

2.2.3 Pros and Cons

Advantages:

Login types are infinitely extensible, reducing development effort for new providers.

Verification status (phone/email) can be unified in a single verified field in the authorization table.

Adding timestamps and IP addresses to the authorization table enables detailed usage tracking.

Core user table remains simple (nickname, avatar, etc.) while authentication details are isolated.

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

Disadvantages:

If a user has several login methods (email, username, phone) and changes the password in one, the others remain unchanged, potentially causing inconsistent login behavior.

Code complexity and logical branching increase, especially when handling various third‑party binding scenarios.

3. One‑Click Login

3.1 Background

The traditional phone+code flow requires entering a phone number, waiting for an SMS, typing the code, and then logging in, which can take 20 seconds or more and depends on SMS delivery.

Instead of SMS, the carrier can verify the device’s SIM card directly, allowing the app to obtain the phone number without user input.

3.2 Device Number Authentication

By retrieving the device’s SIM number, the app can perform a one‑click login, reducing the login time from ~20 seconds to ~2 seconds and improving user experience.

Main steps:

SDK initialization – provide AppKey and AppSecret.

Invoke the SDK to display the authorization page; the SDK contacts the carrier to obtain a masked phone number and presents the carrier agreement.

User consents and clicks login; the SDK receives a token representing the phone number request.

Send the token to the backend, which calls the carrier’s one‑click login API to retrieve the actual phone number, then creates or logs in the user accordingly.

Alibaba Cloud currently offers a compatible one‑click login SDK for the three major carriers (see https://help.aliyun.com/document_detail/121113.html ).

Source: juejin.cn/post/6844904053411938311

Backend‑only technical community – join for high‑quality discussions, recruitment, and knowledge sharing.