Unified Multi-Account Login: Architecture, Flow, and Database Design

Unified Multi-Account Login

Name Explanation

In this context, "multi‑account" refers to using several third‑party identities (e.g., NetEase, WeChat, QQ) to log into an internet application.

Content

Through this article you can learn the technical details of multi‑user solutions, including table design and process flow. No concrete code implementation is provided.

Architecture Evolution

Early Startup Stage

When user volume is low, a self‑built authentication system (username/password) is sufficient.

Username/Password Registration and Login

Typical flow: the front‑end sends credentials, the server validates length, uniqueness, encrypts the password (MD5 + additional encryption), stores it, checks login attempts, applies lockout via Redis expiration, and proceeds with post‑login logic such as points.

Mobile Number Registration and Login

Flow: user submits phone number, server stores it, generates a verification code stored in Redis with a ~10‑minute TTL, user submits the code, server validates it, then logs in. Password can be added later via a supplemental mobile‑password feature.

Database Design

Basic table structure (id, username, password, mobile, error count) that satisfies both schemes.

Auto‑increment ID

Username

Password

Mobile

Error Count

1

user1

7fef6171469e80d32c0559f88b377245

13456789012

0

2

user2

7fef6171469e80d32c0559f88b377245

13456789013

0

Third‑Party Account Integration

Using QQ‑SDK as an example, the sequence includes client‑side login UI, obtaining access_token , openid , and expire_in , server‑side verification, local user creation or lookup, token exchange following OAuth2.0, and token renewal via Redis expiration.

Database Design Details

Four tables are defined:

users : business‑side user record (user_id, token, expire_in, try_times).

user_auth_rel : links users to authentication records (id, user_id, auth_id, auth_type).

user_local_auth : local credentials (auth_id, user_name, password, mobile).

user_third_auth : third‑party credentials (auth_id, openid, login_type, access_token).

The design separates self‑built and third‑party identities, allowing easy extension to additional providers.

Summary

Third‑party integration is straightforward; a dedicated table supports multiple providers, but excessive providers increase maintenance and UI complexity.

The presented solution is a simple, non‑sharded, non‑service‑oriented design suitable for moderate traffic; larger scale would require further enhancements.

Author: Low‑Key Coder